OK, I think I can pin this down now, thanks for your detailed response Pat. (01)
In a nutshell, I agree there is nothing at all 'interesting' about the act of
putting a simple ontology into an OWL file (hence, 'storage') and putting it on
a web server (assuming you can write to the part it serves, of course). The
mechanics of storage and web serving are not a concern. (02)
When a community site does this for multiple ontologies, at times representing
other providers that are defunct or do not want to deal with this new-fangled
ontology stuff (their words, not mine), then some interesting presentation
choices arise. The first (but not simplest) one is designing an appropriate URI
construct that applies to all the different ontologies you are serving. A
second is what 'best practices' for ontology management (versioning, update
rights, labeling, etc.) we want to provide. Then comes the choices about what
services to provide. (03)
I haven't had the time to study the latest incarnation of the requirements, but
some of the first posts included most of the ones I cared about:
- manage core metadata associated with the ontology (when stored, who
provided, rights, previous version, size, ...)
- list and find what ontologies are served (by name, content, or metadata)
- list and find terms within those ontologies (by name, content, or metadata)
- manage extended metadata associated with the ontology (who is using, expert
and other commentary, update frequency, ...) (04)
And of course, providing interfaces for others to manage their ontologies via
my community service (rather than hosting their own repository software). (05)
These are the functions I hope OOR either *does* (writes software for), or
points to reference applications and service providers *for* (where I can
either host the software or utilize the services). Even if all OOR does is
specify a nice list of capabilities and best practices, and how they should be
provided (user interface specs), that would be a start. And the talks I've
heard so far have been great for this purpose! (06)
John (07)
At 11:12 AM -0500 4/21/08, Pat Hayes wrote:
>At 8:02 AM -0700 4/21/08, John Graybeal wrote:
>
>>I am sure hoping we include storage of ontologies, and the associated
>services (and it was explicitly what was discussed as the purpose of the OOR,
>in the first few telecons about it). Otherwise it is of much less use for my
>needs.
>>
>>For our own needs as a community service provider, we have to
>> (a) store ontologies, mostly in OWL, of varying levels of sophstication
>>
>
>The very purpose of OWL, the only reason for it to exist at all, is as a
>language for storing ontologies on the Web, for transmission over the Internet
>using Web infrastructure. Where exactly such an ontology is located is, or
>should be, irrelevant to a user. All the user need know is that it - the
>ontology - has a URI, and giving that URI to the HTTP protocol will cause the
>Web to deliver the ontology back to you. To store and deliver OWL any other
>way would be both inconsistent with its specification and, frankly, insane.
>
>>, and
>> (b) provide a variety of services, at the level of ontological terms (what I
>assume 'components' means in Denise's comments), at the level of the ontology,
>and at the level of providing metadata about the ontology (about both its
>terms and the ontology as a whole). I imagine we will also want to provide
>services about the collection of ontologies that we have. Note that most of
>these services do not require an ontology of ontologies; in the short term the
>effort to develop the ontology of ontologies will just delay my ability to
>provide needed services.
>>
>
>I agree, but was simply reacting to Denise's word 'describe'. I don't think a
>repository needs to be in the description business.
>
>>I am only a beginning/amateur ontologist, so maybe Pat has some definitions
>or assumptions in mind that underlie the responses to Denise's comments, and
>that would make these storage requirements so obviously addressable by "the
>web". If so, it would be helpful to have those definitions or assumptions
>made explicit for the less knowledgeable; I do not see how the web as such
>addresses the needs.
>>
>
>Why then are you using OWL? The middle initial in the acronym is for "Web".
>The OWL and RDF specifications together require that any OWL ontology be
>written as an XML file which has enough information in the headers to enable a
>properly configured browser (or other suitable Web engine) to recognize that
>it should be parsed as RDF, and when it has ben so parsed, to enable any
>conformant OWL engine to further parse it as OWL (or if it cannot be, to
>report a standard error message.) All this is grunt work and about as
>interesting as watching paint dry, but it has already been done. It took a
>long time and lot of effort to get it done. And it works. Now, please tell me,
>why would anyone want to re-invent all this, to store and transmit OWL in some
>other way?
>
>>
>>(In case the reason for my confusion isn't clear: I could imagine saying "I
>can provide all those services layered on top of the ontologies that are out
>there on the web." The two things I wouldn't understand about that are (a)
>how do the ontologies that I have produced get out there, unless I *store
>them* and then serve them
>>
>
>Well yes, of course you do. But we don't need to discuss *how* you store/serve
>them. If you want to know about that, read the relevant specs (RDF and XML,
>chiefly, though the recent http-range-14 decision by the Web Architecture
>group requires some grasp of HTTP redirection in some cases.) My point is only
>that this is all now water under the bridge.
>
>>, and (b) what sense it makes to separate the ontology management (which I
>assume is required to create the ontologies and put them 'out there'
>>
>
>No, it isn't. Strictly, all one needs is a text editor and access to a
>website, though it sure helps to have a more OWL-oriented composing tool.
>
>>) from all of the functions associated with the ontologies.
>>
>
>What 'associated functions' do you have in mind here?
>
>>At a minimum, it would be architecturally odd not to couple the _publication_
>step with the services that construct metadata and serve terms, since you want
>those services to be triggered by any update to the ontology.
>>
>
>Fair enough, but what has publication got to do with storage? You publish
>something by publicizing its URI.
>
>Pat
>
>>)
>>
>>John
>>
>>
>>At 10:22 PM -0500 4/20/08, Pat Hayes wrote:
>>>At 10:29 AM -0400 4/18/08, dbedford@xxxxxxxxxxxxx wrote:
>>>
>>>>Denise's comments --
>>>>
>>>>--->>> I've heard both notions bandied about. Operationally, I think [an]
>OORx
>>>> will have both types of entities. Some organizations will want to
>have
>>>> or provide persistence while others may only wish to host a
>registry.
>>>> This is an architectural decision that will need to be made. In my
>mind
>>>> I think the functionality among a registry and a repository can be
>>>> partitioned in such a way that will allow plug-n-play deployment and
>>>> operation.
>>>>
>>>>Thanks for the reply. In one of the panel sessions there was a discussion
>>>>about the different set of requirements for actually storing versus
>describing
>>>>ontologies.
>>>>
>>>
>>>I think there are other distinctions to be made. Describing ontologies is
>surely to be done by an ontology of ontologies. Being a registry involves
>providing access to ontologies, perhaps providing limited meta-information
>about them and a uniform interface for registering them, maintaining updates
>and so on. None of this need involve actually storing ontologies, which is
>what a repository is supposed to do. Personally, I see absolutely no purpose
>in our even discussing methods for storing ontologies, given the presence of
>the Web. That is a matter of network engineering, not a topic that this forum
>should even be concerning itself with, IMO.
>>>
>>>> At least two of the speakers agreed that two distinct data models
>>>>underlie storing an ontology and describing an ontology. The overlap
>between
>>>>thosee data models -- from my experience working with and describing
>ontologies
>>>>each day
>>>>
>>>
>>>May I ask what are these ontologies that you deal with so often? I am
>surprised to hear that this many ontologies actually exist. What kinds of
>formalism are they written in?
>> >
>>>>-- will be quite minimal. So, in our requirements for an OOR, are we
>>>>targeting the set that is common to both a repository and a registry?
>>>>
>>>> I will argue for a distributed non-hierarchal architecture (e.g.
>flat
>>>> P2P) to meet operational needs.
>>>>
>>>>Whether a registry is centralized or distributed is of less import to the
>>>>registry design. The underlying data model for an ontology repository,
>though,
>>>>cannot be restricted to a question of a hierarchical or non-hierarchical
>>>>architecture. The first design issue is which ongology components must be
>>>>accommodated in the data model, then what type of an architecture is needed
>to
>>>>represent each of those components. A registry can tell us what types of
>>>>components a particular ontology may have, but it may not -- without a more
>>>>explicit data model - be able to house those components.
>>>>
>>>
>>>I find this all very opaque. What do you mean by a 'component' of an
>ontology?
>>>
>>>Pat Hayes
>>>--
>>>---------------------------------------------------------------------
>>>IHMC (850)434 8903 or (650)494 3973 home
>>>40 South Alcaniz St. (850)202 4416 office
>>>Pensacola (850)202 4440 fax
>>>FL 32502 (850)291 0667 cell
>>>http://www.ihmc.us/users/phayes phayesAT-SIGNihmc.us
>>>http://www.flickr.com/pathayes/collections
>>>
>>>
>>>
>>>_________________________________________________________________
>>>Message Archives: http://ontolog.cim3.net/forum/oor-forum/
>>>Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx
>>>Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/
>>>Shared Files: http://ontolog.cim3.net/file/work/OOR/
>>>Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository
>>
>>
>>--
>>----------
>>John Graybeal <mailto:graybeal@xxxxxxxxx> -- 831-775-1956
>>Monterey Bay Aquarium Research Institute
>>Marine Metadata Interoperability Project: http://marinemetadata.org
>>
>>Shore Side Data System: http://www.mbari.org/ssds
>>
>
>
>--
>---------------------------------------------------------------------
>IHMC (850)434 8903 or (650)494 3973 home
>40 South Alcaniz St. (850)202 4416 office
>Pensacola (850)202 4440 fax
>FL 32502 (850)291 0667 cell
>http://www.ihmc.us/users/phayes phayesAT-SIGNihmc.us
>http://www.flickr.com/pathayes/collections (08)
--
----------
John Graybeal <mailto:graybeal@xxxxxxxxx> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project: http://marinemetadata.org
Shore Side Data System: http://www.mbari.org/ssds (09)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/oor-forum/
Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/
Shared Files: http://ontolog.cim3.net/file/work/OOR/
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository (010)
|