One of the problems with not taking into account the repository model
is that a registry, when asked for all the statements about a
resource, will not be able to answer the complete set of statements
(include infer ones) in a descend amount of time. For example: (01)
1) I have an ontology A and an ontology B, that two organizations
could submit ( let say registering a URL, that points to the OWL file)
2) There is a third ontology, ontology C, that declares relations
between A and B. For example termA is a term of ontology A and termB
is a term of ontology B. The statement in ontology C says termA
subclassOf termB.
3) If I ask the registry about statements about termA, the registry
should include the previous statement, and possibly any infer
statements, as well.
So, if the registry, every time is being queried, is going to reach
all the URLs it knows, check if something about a resource has being
declared, create a graph, infer statements and respond, then it is
going to consume a lot of time. (02)
So there is a need to have a repository to cache the statements, the
graph, the inference model, etc. Another benefit is: if on ontology is
registered, but then the original location is not available ( e.g.
site is down ) then the registry uses its repository version to
access it. (03)
This is why the underlying data model of the registry is important.
For example are we talking about an ontology being composed of
triples, every time I register an ontology the triples are extracted
and stored in the repository. Then the registry is able to respond
fast to any query about the ontologies and the concepts contained,
which I think is what I will use the registry for. (04)
-luis (05)
On Apr 21, 2008, at 1:07 PM, Pat Hayes wrote:
> At 9:45 AM -0700 4/21/08, John Graybeal wrote:
>> OK, I think I can pin this down now, thanks for your detailed
>> response Pat.
>>
>> 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.
>>
>> 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.
>>
>> 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, ...)
>>
>> And of course, providing interfaces for others to manage their
>> ontologies via my community service (rather than hosting their own
>> repository software).
>
> Agree with all the above. But none of that has to do with storage. I
> see all this as what a registry would be doing. Our COE tool, for
> example, performs several of these services for OWL ontologies (term-
> level search, in particular) without needing to know any more about
> them than their URI.
>
> And I think it would be good engineering to use Web ideas as far as
> possible to implement the missing functionality. For example, OWL
> itself has some provision for low-level metadata attachments (using
> rdf:seeAlso and OWL annotation properties), and more sophisticated
> metadata could be itself be expressed in OWL/RDF and 'attached' to
> the parent ontology by a suitable owl:import assertion. There are a
> lot of handy tools and APIs and general infrastructure available now
> for doing this kind of stuff.
>
> Pat
>
>>
>> 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!
>>
>> John
>>
>>
>> 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
>>
>>
>> --
>> ----------
>> 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
>
>
>
> _________________________________________________________________
> 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 (06)
___
Luis Bermudez Ph.D.
Coastal Research Technical Manager
Southeastern Universities Research Association (SURA)
bermudez@xxxxxxxx - Office: (202) 408-8211 Mobile: (267) 481-4939
1201 New York Ave. NW Suite 430, Washington DC 20005 (07)
_________________________________________________________________
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 (08)
|