|
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 (01)
|