OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [uddi-spec] Porp 028 owl 20040323


Max,

I have added comments below.

I am sure we will get to discuss this in more detail next week.

John Colgrave
IBM

> Lines 135-137
> 
> You say that we go with a subset of OWL Full, but given the number of
> elements allowed in the UDDI OWL it is not a superset for OWL lite.

I am not sure what you are saying here.

If an ontology does not use the uddi:abstract attribute (which I am thinking
of renaming to uddi:disallowed or similar) then the subset of OWL which UDDI
will recognize as a minimum is a subset of OWL Lite.  The version of the
UDDI types taxonomy contained in draft 0.1 of this proposal was in OWL Lite.

If an ontology does use uddi:abstract, then it is in OWL Full but in terms
of what a UDDI implementation will be required to understand, we have only
added a single DatatypeProperty so although we now have a subset of OWL Full
it is not much bigger than the subset of OWL Lite.  The version of the UDDI
types taxonomy contained in draft 0.2 of this proposal is in OWL UDDI and I
believe contains examples of all of the elements in OWL UDDI, so this is as
complicated as OWL UDDI gets.

We could choose to use an AnnotationProperty (effectively a standardized
comment) instead of a DatatypeProperty but I think it is better to use a
DatatypeProperty even though it takes us into OWL Full.  I think the uses of
this property will be rare and the vast majority of UDDI value sets would be
able to be represented in the subset of OWL Lite.

Note that one of the advantages of the RDF-based approach is that the UDDI
specifics can be added in a separate ontology so the original ontology could
be in OWL Lite and then if someone wants to use that with UDDI, including
using abstract/disallowed, then they can produce a separate ontology and
import the original ontology and add the UDDI specifics in this new
ontology, which will be in a subset of OWL Full but the original ontology is
unchanged and still in OWL Lite.

> Basically, the ontologies will have to be written for UDDI specifically
> and
> very few ontologies fully complient to any flavour of OWL will be valid
> for
> the UDDI OWL.
> Please, correct me if I'm wrong.

If you mean that ontologies will have to be written to this subset to be
portable between UDDI implementations then that is true, although one of he
advantages of starting with a subset of OWL rather than a proprietary
language is that it will be easier for implementations to offer enhanced
support for OWL so that they can accommodate a greater range of ontologies.

We may even decide to accommodate more of OWL than the bare minimum.  The
purpose of this proposal is to show the smallest subset of OWL that is
adequate to meet the requirements for a UDDI taxonomy language.  As we look
at REQ-029 and potentially OWL-S support we may end up incorporating more of
OWL.

> Lines 413-414
> 
> You suggest a restriction on rdf:ID values which will also require
> redevelopment of ontologies to make them valid for the UDDI OWL.

I don't suggest the restriction, the restriction comes from RDF.  I am
suggesting a best practice for representing taxonomies in RDF/OWL that have
numeric identifiers.  There was a DAML=OIL version of UNSPSC produced that
had nothing to do with UDDI and they also faced this same issue.

> Genral comments
> 
> How these ontologies will be used?

They will be used in place of the proprietary representations of all UDDI
value sets that implementations use currently.

> Will they be parsed by a UDDI server and used for searches?

Yes, they will be used just like value sets are today, as a minimum.

> Do we plan any additional API for this?

There are some additional requirements although I am not yet personally
convinced that we need them, and I certainly think they should be separated
from the requirements on a standard value set language, which is what my
proposal aims to address.

> Do we get enough improvement in UDDI capabilites to warrant the
> implementation effort If we restrict OWL to something that is neither Lite
> nor Full?

I think so.  I think it will be very useful to have a standard language for
representing value sets so that they can be portable between UDDI
implementations.  I think that there are significant advantages to using a
subset of OWL for this language rather than inventing a proprietary one just
for UDDI.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]