I should expand on this.
My current thinking is that a standard
language for representing UDDI taxonomies could be provided by a subset of OWL
Lite (“OWL UDDI”?) which involves only OWL class definitions and
the association of UDDI entities with one or more of those classes.
If this turns out to be the case then what
I said holds true.
If we end up supporting instances with
properties then things get more complicated and you could regard the set of
class and property definitions as a schema against which you have to validate
the set of instances. I think this is the kind of thing that you were
worried about.
I am hoping to write up a proper OWL
proposal shortly, at which time it should be clear if the simple approach will
be adequate.
-----Original Message-----
From: John Colgrave
[mailto:colgrave@hursley.ibm.com]
Sent: 08 March 2004 12:10
To: 'Tom Bellwood'
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] My
thoughts on OWL etc.
Tom,
There is no such thing as “a
different OWL schema” for each ontology. You can think of OWL as a
schema and each OWL ontology as an instance of that single schema.
What I am suggesting is that we provide a
normative interpretation of a subset of OWL rather than inventing our own
“proprietary” equivalent of a subset of OWL.
-----Original Message-----
From: Tom Bellwood
[mailto:bellwood@us.ibm.com]
Sent: 08 March 2004 02:29
To: John Colgrave
Cc: uddi-spec@lists.oasis-open.org
Subject: Re: [uddi-spec] My
thoughts on OWL etc.
Hi John,
My apologies for being dreadfully behind on this topic now, but regarding your
comments, if we were to support any OWL ontology, how would we load and
validate it in UDDI? It certainly seems that doing so is indeed a requirement
though. Being able to digest, reference and represent (for UI applications) the
subset taxonomies internally has been requested by many a customer of the
various UDDI providers. How do we reasonably import, represet, manipulate and
check taxonomies if they can stem from any OWL compliant ontology, each of
which is ruled by a different OWL schema? I think that what drove the
simplification to a single "XML" schema at the FTF was the need to
support these capabilities without having to solve the complex problem of
supporting any arbitrary OWL schema for purposes of validation of the import.
Perhaps we've overlooked a reasonable solution for this. Do you have further
thoughts?
Thanks,
Tom Bellwood Phone: (512) 838-9957 (external); TL: 678/9957 (internal)
Co-Chair, OASIS UDDI Specification TC
STSM - Emerging Technologies
IBM Corporation
To: <uddi-spec@lists.oasis-open.org>
cc:
Subject: [uddi-spec] My thoughts on OWL etc.
Having read
the minutes of the FTF discussion on Taxonomy Management etc. I
think that some of my views were not accurately
presented, and some of them
have clarified, so I thought I would try and write
down what my current
thoughts are. I also have a few comments on
the discussions minuted.
My concern with
Luc's approach is that it is using OWL to define a schema,
which is not what OWL is intended for. OWL
is intended for defining
ontologies, and an equivalent of a UDDI value set
can be viewed as a subset
of an ontology. I think the choice to be
made is between using (something
like) OWL as it is intended to be used, similar to
my excerpt of a UNSPSC
ontology/taxonomy, and using XML Schema to create
a UDDI-specific schema for
value sets.
I think this
choice will have an impact on how many of the other
requirements it is necessary to address in UDDI,
so we need to make it
before progressing much further with the other
requirements.
I think it
would be better to profile something like OWL than to invent
something specific for UDDI. I said in my
response to Luc that I thought
that OWL was the best candidate at the moment, and
now that it has become a
full W3C Recommendation it is an even better
candidate.
I am not
convinced of the need to have standard APIs for saving and managing
ontologies in UDDI, and navigation is one area
where a standard API may
evolve in the context of OWL so it would be better
for that to be used than
an equivalent API defined just for UDDI.
Contrary to
the FTF minutes, this view is not "largely based on the premise
that semantic search capabilities should be
exploited by inferencing engines
external to a UDDI server", it is based on
the assumption that it is better
to use a standard such as OWL (in the way in which
it was intended to be
used) rather than inventing a specific language
just for UDDI, so that we
can benefit from ontologies/taxonomies created by
other groups, with perhaps
no knowledge of or interest in UDDI, and also so
that we can benefit from
tools and APIs that are being developed for OWL.
I am not thinking about
inferencing at the moment.
I was a
little surprised by the discussion of equivalency as I did not
realize that it was a requirement, or something
that was currently
supported. In OWL you can express
equivalence between classes. This is
intended for equivalence across ontologies but I
guess you could use it
within an ontology if that made sense.
I don't
understand why both "Define a standard format for representing a
value set" and "Define an XML-based
schema for representing value sets" are
listed as being in the minimal set of features.
I am
concerned that restricting value set relationship support to a single
root node relationship tree will prevent UDDI from
using standard ontologies
defined without such a restriction in mind.
For example, if someone were to
produce a full OWL version of UNSPSC, we would
probably not be able to use
that in UDDI as it would probably not have a
single root node.
As another
example, the National Cancer Institute Thesaurus is available as
an OWL ontology that is 32MB and which contains
just over 500,000 RDF
triples. I think that there are multiple
top-level classes in this
ontology, there is no single root class. I
would like to be able to use
that ontology directly, rather than have to transcribe
it to a UDDI-specific
format, or even add an unnecessary root node.
John
Colgrave
IBM
To
unsubscribe from this mailing list (and be removed from the roster of the OASIS
TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.