Use cases for the OOR and SIO would and should overlap because they
will naturally be used together. One could, of course, use them
separately, but ideally the OOR will contain a basic set of modules
(theories) that almost everybody would want to use to build an
ontology of any size. Furthermore, the SIO project will develop
the tools that make the OOR more than just a library. (01)
RW> If the OOR is only to support ontology developers, then it is
> at best an academic exercise and the real ontology work will
> move elsewhere. It has to help application developers find
> the ontologies that they need and to understand which ones
> can be used together. (02)
Among the use cases for both the OOR and SIO are support for
the ontologies necessary for software design and development.
That implies a very large overlap with what the OMG is doing.
See below for a copy of a note I sent to an OMG email list. (03)
CR>> The OOR is federated. So there is no central repository. (04)
RW> I hope that the SIO will produce a structure similar to Maven
> so that local and central and federated repositories can be built
> the way Nexus is used to manage and distribute software artifacts. (05)
If the OOR has a good set of basic ontologies, it will become
the first choice for anybody who wants to start or extend any
kind of ontology development. (06)
If the SIO tools are sufficiently flexible and usable, they
will be adopted by anybody who wants to start or extend any
kind of ontology development. (07)
I cited Eclipse as an example, because developers for small
businesses, large corporations, and open-source projects
all use it and contribute to it. (08)
I hope that we can attract the same people who use Eclipse,
but we must also support the Semantic Web, SOA projects,
and document processing of any kind. (09)
John (010)
-------- Original Message --------
Subject: Re: Business and logical view of processes
Date: Sun, 11 Apr 2010 10:53:52 -0400
From: John F. Sowa
To: architecture-ecosystem <architecture-ecosystem@xxxxxxx> (011)
Folks, (012)
I'd like to point out that if this project is successful, the total
amount of content will become truly immense. It will never become
as large as the full WWW, but every well thought-out viewpoint (a
tiny, but still enormous subset of the WWW) will be represented. (013)
As with the WWW, the basic information may be contributed by
humans, but the organization and structure of that information
requires automated tools. If you have suitable tools, you don't
need a hub-and-spoke organization to manage the information. (014)
Some comments: (015)
JA> The integration is implemented in the 'hub out' since that's
> where the shared information is linked. (016)
If you look at the WWW, the automated tool for sharing, organizing,
and finding information is an "afterthought" named Google. We need
something more structured than Google's indexing service, but it
must be as flexible, automatic, and easy to use as Google. (017)
VLH> Why not make the solution space inclusive of composition and
> extension as well? This is where the real issue is anyway:
> (e.g. "How do I use this kind of model to help my part of
> the solution?? I know! I will just ignore it!") (018)
That shows why the system must be as automated and easy to use
as Google. People don't ignore Google, because Google indexes
everything, and it's easier to use it than to ignore it. It
conforms to the fundamental principle of Human Factors: (019)
If you want people to be virtuous, you have to make virtue
the path of least resistance. (020)
For example, I have advocated a lattice structure, which supports
multiple inheritance. But people often complain, (021)
"Oh, no! You can't have multiple inheritance because it creates
inconsistencies when people specify multiple inheritance links." (022)
I agree. I would never ask anyone to specify more than one
inheritance link. In fact, I would never ask them to specify
*any* inheritance links. (023)
The reason why we need a lattice is that the software *automatically*
determines the inheritance links. For example, check Google for FCA
(Formal Concept Analysis). Given a set of concepts described by a
collection of attributes, the FCA tools automatically determine the
minimal lattice that specifies all the inheritance links among those
concepts. (024)
People even use the FCA tools to verify that OWL ontologies are
consistent. For more info, use Google to search for "FCA OWL"
(but throw in the word 'concept' to reduce the ambiguity). (025)
There is much more to be said about this topic, including many more
qualifications, caveats, and suggestions. But a system of the kind
we have been discussing *requires* automated and semi-automated
tools for organizing, relating, and maintaining the structure. (026)
If you have suitable tools, the requirements for human management
and administration are drastically reduced. Before Google, there
were many attempts to develop human-contributed classifications
to support Yahoo and other systems. But the automated methods
of Google made all those human-based indexes obsolete. (027)
For this project, we need more structure than just an index,
but the tools that derive the structure must be automated.
There are also semi-automated methods such as folksonomies,
which have some useful properties, but more structure is
needed than the typical folksonomies support. (028)
John Sowa (029)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/sio-dev/
Join Community: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/sio-dev/
Unsubscribe: mailto:sio-dev-leave@xxxxxxxxxxxxxxxx
Community Shared Files: http://ontolog.cim3.net/file/work/SIO/
Community Wiki:
http://ontolog.cim3.net/cgi-bin/wiki.pl?SharingIntegratingOntologies (030)
|