> [RonW] I hope that this project can take the experience
> of Maven and its repositories (Nexus is only
> one of the repositories available) that are supported by
> Eclipse, to build a really useful tool set that can make it
> easy to find and integrate ontologies.
>
> The Maven team provides a repository into which software
> developers can upload their artifacts. (01)
[ppy] thanks, Ron. Are you part of the Maven or Nexus team ... or do
you know someone who plays a key role on that team, who was involved
in making some of their design decisions? It would be nice to run a
panel session of software repository developers, and invite these
people over to share with us their experience and insights. (02)
More ideas along this line ... anyone? (03)
Thanks & regards. =ppy
-- (04)
On Sun, Apr 11, 2010 at 11:45 AM, Ron Wheeler
<rwheeler@xxxxxxxxxxxxxxxxxxxxx> wrote:
> +1 for Eclipse.
> I hope that this project can take the experience of Maven and its
> repositories (Nexus is only one of the repositories available) that are
> supported by Eclipse, to build a really useful tool set that can make it
> easy to find and integrate ontologies.
>
> The Maven team provides a repository into which software developers can
> upload their artifacts.
>
> Availability of an artifact does not imply that the artifact works or that
> it is compatible with any other software built by other organizations or
> individuals.
>
> Ron (05)
> On 11/04/2010 12:16 PM, Cameron Ross wrote:
>
> On Sun, Apr 11, 2010 at 12:00 PM, John F. Sowa <sowa@xxxxxxxxxxx> wrote:
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> CR>> The OOR is federated. So there is no central repository.
>
> Above comment was made by kenb not CR.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> I cited Eclipse as an example, because developers for small
>> businesses, large corporations, and open-source projects
>> all use it and contribute to it.
>
> The reasons noted above are good ones for considering Eclipse
> (i.e. acceptance and adoption). But my primary motivation for
> promoting Eclipse are more technological. Eclipse provides a huge
> collection of tool components that are well integrated. It also
> provides a proven architecture for modular tool development.
> All of these things are not easy to replicate, so its most
> efficient to leverage what already exists.
>>
>> 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.
>>
>> John (06)
>> -------- 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>
>>
>> Folks,
>>
>> 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.
>>
>> 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.
>>
>> Some comments:
>>
>> JA> The integration is implemented in the 'hub out' since that's
>> > where the shared information is linked.
>>
>> 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.
>>
>> 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!")
>>
>> 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:
>>
>> If you want people to be virtuous, you have to make virtue
>> the path of least resistance.
>>
>> For example, I have advocated a lattice structure, which supports
>> multiple inheritance. But people often complain,
>>
>> "Oh, no! You can't have multiple inheritance because it creates
>> inconsistencies when people specify multiple inheritance links."
>>
>> 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.
>>
>> 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.
>>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> John Sowa (07)
_________________________________________________________________
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 (08)
|