> Thanks Elisa for further points
> It looks to me that what you describe below, fits the requirement for
> one customer, or one class of customers. I do not exclude that
> particular requirement you outline below can be bet with a repository,
> as it can be met with a schema which produces the desired
> functionality irrespective of where the ontology resides.
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.
If an ontology or vocabulary is defined through a standards body, then
it should be published by that standards body and evolve through their
processes in such a way that its users understand how and when it will
"How" an ontology is published - on some public web server, through a
virtual repository (which may or may not be implemented through
traditional database technology), or otherwise - is only one of a number
of issues that the should be addressed by Ontolog's open ontology
repository initiative, in other words. And yes, I agree wholeheartedly
that identification of a user community and development of use cases are
> If this project has to serve the requirement of your customers, that's
> a different story
> But if this project must serve 'universal' requirements, including the
> ones that have not yet been specified, of unknown users, then the LOD
> concept is the most open, cause it allows any operation to be carried
> out at any level, as defined at query/resoner level
Perhaps, but the "implementation strategy" for publication, which could
include an LOD-compatible approach, is less important than the
stewardship and management process, regardless of who publishes it.
> >From what I understand, an LOD based systems can also combine data (an
> ontology) stored in different types of repositories and in different
> locations, and I cannot see any limit to the functionality that can be
> developed on top of it
> The key notion is 'distributed', which contrasts with centralized.
> The 'centralization' of a distributed environment is done at schema level/
Here is where I believe that the use cases will be critical. Every
ontology published and managed by this group, in order to be useful to a
community of interest, needs a steward, and maintenance policies should
be clear to anyone who might depend on it. Otherwise, we will publish
lots of ontologies that very few people will ever use.
> Of course there are issues, but users, say OMG customers, can always
> freeze some bits of it and place whatever they want behind a wall and
> control it as per their organisational model. Nothing would prevent
> anyone from doing such a thing
Change management policies are critical for broad adoption, though.
People really do need to know that their application will continue to
work properly even though someone else on a distant island has changed
the ontology it is based on, or at a minimum, they should be able to
continue to use the older version and be able to make that choice
actively. This is a much deeper issue than the implementation strategy
to publish the ontology in my view. Examples include Dublin Core, SKOS,
FOAF, and a few others ... including the FinnOnto project in Finland
(http://www.seco.tkk.fi/projects/finnonto/). In each case, you find a
small community of developers who are dedicated to supporting a much
broader user community -- including publishing their maintenance
policies, inviting user feedback, actually responding to that feedback,
etc. Any effort sponsored by Ontolog needs to take these issues into
consideration, which could be compatible with an LOD approach, but it
needs careful thought.
> It goes without saying that best practices and standards, where
> available, have to applied in either case.
> The repository as it is being discussed here, from what I understood
> of it, is an enhanced database, somehow ontology repository can become
> a bit of an oxymoron, if we consider the context of the open web.
> Requirements of individual customers are very different from universal
> requirements of wider groups of web users.
> So maybe one step forward in this debate is identifying the intended
> users of this system that Ontolog is trying to satisfy (other than OMG
> customers), .....
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
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 (05)