I hope that John's ideas are being included in the OR requirements. (01)
I am not an expert in this area but have been around a lot longer than most.
I suspect that once an application designer has selected a set of
ontologies, he is committed to the snapshot at some instant in time. The
set of ontologies that is selected will be modified to suit the
application and the management style of the client.
Anyone who thinks that every organization in an industry has the same
view of the universe has never tried to sell or install a major
application. The budget for merging the IT systems in 2 banks can run
into tens of millions even if they use the same money and offer the same
types of services and have been exchanging data every night for decades. (02)
There will be opportunities to revisit the original ontology selection
and decide if updates are appropriate but these will be few and far
because of the high risk involved.
Most of the time, once you make your selection, you have created a
branch of the original ontology and you are committed to maintaining it
yourself. (03)
I suspect that revision control similar to CVS or Subversion would
suffice for the core ontology. (04)
I am not sure how any OR is going to keep reviews and lists in synch
with the ontology. (05)
License holders may be unwilling to release the ontology to a public
body without some protection but you still want to include proprietary
ontologies in the library. (06)
If you follow the model of tight central control over the OR as hinted
in 3) below, you will require significant staff and some standards body
to decide who gets to pick the committers. If this is too restrictive,
it will slow down the process and lead to competing ORs and no standard
being accepted. (07)
A standards body that has an explicit buy-in from its members (industry
with EDI standards, for example) is in a much different situation than a
standards body that depends on the wisdom of their decisions to gain
acceptance. (08)
Ron (09)
John F. Sowa wrote:
> John G, Elisa, Ron,
>
> JG> I ask because I'm not sure why this group is devoting time
> > discussing design of a system, when the interested parties
> > might instead agree on basic goals, pick a system, and start
> > work? Or else I am missing something.
>
> The critical issue is to *relate* different ontologies or the
> modules from which ontologies can be built to one another and
> to provide a systematic framework for evaluating them. There
> are many different ontologies that people can pick, but it is
> desirable to have a framework for showing how they are related.
>
> It is also necessary to include reviews, evaluations, and
> comments by actual users of any ontology.
>
> EK> ... we have customers who want to ensure that certain
> > ontologies (even "open source" ontologies) that they elect to
> > depend on are developed and managed in processes similar to
> > those of typical standards bodies...
> >
> > The more important issue I think is one of stewardship --
> > irrespective of where ontologies "reside" from a linked data
> > perspective, one would hope that there is a community of interest
> > that is responsible for evolving and managing that ontology in
> > a way that others can depend on.
>
> That is essential for anything that businesses are going to
> adopt for any mission critical applications.
>
> For relating ontologies and modules, there is no need to "design"
> a system, since there is (and always has been) a natural system
> for relating theories: it's called the Lindenbaum lattice, which
> shows how theories are related to one another as specializations,
> generalizations, or siblings.
>
> Whenever two or more modules are combined to form a larger theory,
> the result is always a common specialization of the starting modules.
> Any deletion of an axiom from a theory makes it more generalized;
> any addition of a nonredundant axiom makes it more specialized.
> For a brief summary of the lattice of theories and its application,
> see Sections 2, 3, and 4 of the following paper:
>
> http://www.jfsowa.com/logic/theories.htm
>
> Since the complete lattice of all conceivable theories is infinite,
> there are many more than anyone would ever document or implement.
> Therefore, I suggest the term 'hierarchy of theories' for those
> that have been documented in the registry.
>
> As far as storing the theories, we need something more than
> a list of links to ontologies scattered across the WWW:
>
> 1. Links to web sites have a notoriously short lifetime, and the
> owners of any given site tend to change or move the contents
> of any page at unpredictable, usually inconvenient times.
> Furthermore, the reviews and evaluations should be linked
> to and from the ontologies.
>
> 2. We need policies for version control, reviewing, evaluating,
> testing, relating, and commenting on ontologies. The policies
> should also standardize the required metadata for each
> contributed ontology, the licensing information, etc.
>
> 3. The metadata, comments, reviews, and evaluations should be
> linked to and from the ontologies, but controls are needed
> to prevent unauthorized modification or deletion of anything.
>
> 4. The repository may be virtual, but the methods of version
> control should ensure that all previous versions of any
> contributed ontology (and metadata) are available under
> their original URIs, independently of where they may be
> physically stored.
>
> RW> If someone already has an open repository where the metadata
> > about an ontology can be uploaded by anyone who wants to and the
> > community can post comments and create links between ontologies,
> > then lets all support that.
>
> There are many good resources available on the WWW, but I am not
> aware of anything that comes close to meeting the above criteria
> for maintaining, evaluating, relating, and organizing an open-ended
> and growing collection of ontologies. If anyone knows of any such
> things, please let us know.
>
> John Sowa
>
>
> _________________________________________________________________
> 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
>
>
> (010)
_________________________________________________________________
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 (011)
|