[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [uddi-spec] Porp 028 owl 20040323
Apologies if this ends up on the list twice. It did not seem to make it the first time. John Colgrave IBM -----Original Message----- From: John Colgrave [mailto:colgrave@hursley.ibm.com] Sent: 25 March 2004 10:16 To: 'Max Voskob'; 'uddi' 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]