Len, (01)
That was the major motivation for moving from file systems to database
systems in the 1960s and to relational DB systems in the 1970s: (02)
LY> How do you maintain a body of knowledge useful and accessible to
> many different application (since cost of developing a general
> knowledge is not going to be justifiable for a single application)? (03)
When you bring in the WWW, the problem escalates. But it's important
to recognize that large enterprises had world-wide intranets long
before Arpanet became the Internet. DB systems, both relational
and object-oriented, had been processing terabytes and petabytes
when the Semantic Web was just getting started. (04)
LY> Far from defending SemWebbers - I don't think they are ignorant
> crowd. (05)
I agree that there are many very intelligent researchers working
on the Semantic Web. But I believe that they could make bigger
*and* better contributions if they were working independently
rather than in a huge committee. Too many cooks spoil the broth. (06)
Note that Google was started by a very small group at Stanford
at around the same time that Tim B-L published his book. But
Google grew much bigger and much faster than the SemWeb -- and
their technology is much more scalable. (07)
LY> To begin with - sW technology is primarily about Web (sorry for
> offending anyone with small "s"). But it does address the main
> challenge that is in my view -scalability. That does not disqualify
> it from achieving "S" in some cases. In fact they are very good at
> identifying these cases and dividing the problem space into specific
> areas with different performance characteristics. So I would start
> with looking at SW literature for technical incites. (08)
The SW has the strengths and weaknesses of a large committee. Instead
of a clean, elegant, streamlined solution, you get a compromise that
includes everything plus the kitchen sink. As an example, just look
at the RDF notation for triples compared to the notation that Google
uses: {A, B, C}. That is the JSON notation, which also supports
n-tuples, objects, and typed or untyped terms and lists. (09)
I think that *ideology* is the main obstacle that has strangled
innovation in the SW. If anybody whispers that JSON might be better
than RDF, the SW thought police immediately exile them from the empire. (010)
JFS>> Protégé is useful for generating OWL, but OWL is not integrated
>> with what business software developers, vendors, and the people
>> who develop enterprise data bases and knowledge bases actually do. (011)
LY> That is true about Protege v4 which is based on OWL. However,
> Protege is designed to be highly extensible and flexible. It
> definitely can support enterprise applications and can be scaled up
> significantly. Protege versions before v4 were based entirely on
> frames (not OWL). I used Protege 3 to integrate it with data bases
> for enterprise application development. You can download the OntoBase
> plug-in I developed for that http://www.ontospace.net/ontobase (012)
Protege is a good system, and the Stanford group should be given a lot
of credit for developing such a widely used tool. But just compare
two groups that both started at Stanford around the same time: (013)
1. Google became a multi-billion dollar enterprise, which indexes
all the publicly accessible web pages on the Internet. They have
professionally developed tools that scale to all that data. When
they combined asynchronous JavaScript with XML to support Google
Maps, developers around the world immediately adopted it, renamed
it AJAX, and made it the foundation for thousands of web sites. (014)
2. Protege is still a small group with software developed by student
labor, and it depends on free plug-ins written by individuals
who want to apply it to business applications. (015)
JFS> If you want to support business applications, you have to work
>> with the people who develop business applications. And you have
>> to make sure that your tools are integrated with their tools. (016)
LY> And Protege is still the best tool for that. (017)
As long as a university project remains the primary tool, you don't
have a scalable methodology that can support a major enterprise. (018)
John (019)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (020)
|