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: FW: [uddi-spec] Examples of Value Set Representations - OWL and Microsoft's Extensions Schema


Further to this, I have attached a first attempt at defining a small subset of UNSPSC as an OWL ontology/taxonomy.

 

This was probably not the best choice of example, as in looking into this I think there are some issues around how we currently support UNSPSC in UDDI but that will be the subject of a different note.

 

I have chosen to represent UNSPSC codes as classes in multiple taxonomy trees – there is no need for a single artificial “root”.  I have prefixed the codes with ‘_’ to make the resulting strings valid IDs.

 

I believe that this taxonomy is expressed in OWL Lite, and it is a taxonomy rather than an ontology as there are no properties defined on the classes.

 

I chose not to model the Segment/Family/Class/Commodity structure of UNSPSC as I believe that would require OWL Full.

 

There are no individuals defined, only classes.

 

I think we probably should differentiate between referring to classes in the taxonomy and referring to instances, in the cases where there are instances defined in the taxonomy/ontology.

 

As I said in my previous note, there are several ways we could express the association of a UDDI entity to a taxonomy/ontology.  We could do it using the existing keyedReference approach, for example we could have a tModel to represent the UNSPSC taxonomy as we do today and we could use a keyValue of “_90121602” to refer to the UNSPSC “Visa or auxiliary document services” commodity.  This would be almost identical to what we do today.  Alternatively, we could do it in OWL or RDF.

 

I think this style of taxonomy/ontology is simple enough that a UDDI registry could continue to provide it, and similar user-defined taxonomies, as internal, including doing validation, but this brings us back to one of the fundamental questions in all this which is how much taxonomy/ontology-related function should a UDDI registry provide.

 

John Colgrave

IBM

 

-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent:
06 February 2004 10:38
To: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Examples of Value Set Representations - OWL and Microsoft's Extensions Schema

 

Luc,

 

This approach is completely different to the way I have been thinking about this so thanks for taking the time to put this together to stimulate the discussions.  I wish I could be at the meeting next week.

 

My view is that we should do as little that is UDDI-specific as possible so that we can make use of standard ontologies, tools, APIs etc. and not require people to do extra work specifically for UDDI.

 

I will use OWL as an example as I think it is the best candidate at the moment, but I think that one of the first things we should do is to decide whether we are going to back one horse or try and hedge our bets.

 

I was not thinking of OWL as a kind of schema language in which we would describe what a UDDI Value Set looked like.  I was thinking of enabling UDDI to use any ontology expressed “natively” in OWL.  What advantage is there in using OWL in this way compared to XML Schema?

 

If we wanted to restrict people to taxonomies then the OWL Guide suggests [1] that only using classes and individuals, without properties, is sufficient for taxonomies, there is no need for some kind of UDDI Value Set schema/ontology.  However, it is not clear to me that this extra restriction is necessary.

 

Take as an example the OWL wine ontology at [2].  I think we ought to be able to declare that a UDDI businessEntity is a Winery in the sense of this ontology, or perhaps that the businessEntity represents an individual Winery such as SchlossVolrad (categorization compared to identification).  There are (at least) a couple of ways that we could do this without a fundamental change to the UDDI data structures:

  1. We could have a single tModel for any OWL instance and use a keyedReference with a keyValue of “http://www.w3.org/TR/2003/CR-owl-guide-20030818/wine#SchlossVolrad
  2. We could have a tModel for the wine ontology and use a keyedReference with a keyValue of just “SchlossVolrad”

 

I think a fundamental question is whether we are going to restrict references in UDDI entities to existing instances in the ontology, or whether we are going to allow UDDI entities to define new instances and extend the ontology.

 

I do not think that we should expect somebody to have to rewrite this OWL ontology to fit the restrictions of a UDDI Value Set, or to write a UDDI Value Set as some kind of proxy for the ontology, to incorporate UDDI-specific things such as tModelKey and the simple parentValue relationship.  I don’t think it is necessary and I think you lose a lot of the capability of OWL.

 

Similarly, I do not think we should be inventing UDDI-specific APIs unless absolutely necessary.  I think we need to decide how closely we should integrate ontologies into UDDI before we can decide what APIs may be necessary.  I guess the biggest issue is validation.  This is the main reason I can think of for us to consider having UDDI APIs to define, publish and manage.  I have already posted a few references to OWL tools and APIs and I think we need to be clear that we are providing sufficient value before we decide to impose a UDDI-specific solution and cut people off from using these other solutions.

 

As I am sure you have realized, what I have described is an external approach whereas what you described is an internal approach.  Another fundamental question is whether or not we support one or the other, or both.  There will certainly be more work involved in supporting “native” OWL ontologies internally compared to your Value Set approach.

 

1 http://www.w3.org/TR/2003/PR-owl-guide-20031215/#SimpleProperties

2 http://www.w3.org/TR/2003/PR-owl-guide-20031215/wine.rdf

 

John Colgrave

IBM

 

-----Original Message-----
From: Luc Clément [mailto:luc@iclement.net]
Sent:
06 February 2004 04:25
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Examples of Value Set Representations - OWL and Microsoft's Extensions Schema

 

In order to help us make progress at the FTF on our requirement to select a value set schema and define a set of associated APIs to define, publish, manage and navigate these value sets, I’m providing for purpose of example 3 different value sets: the uddi-org:types value set; an excerpt of the MS Business Capabilities Classification Scheme [3]; and an excerpt of the MS MapPoint Geographic Context Hierarchy [4]. Two of these [3, 4] are available from Microsoft in its UDDI Services Extensions schema format [1, 2] (which I’m familiar with due to past experience). I’ve also formatted these three iaw an OWL schema I’ve created (…rather blindly due to the lack of adequate tooling and sufficient background in RDF/OWL). My purpose for doing so is to demonstrate different means of representing value sets; there are clearly many other alternative representations. The intent is to allow us to discuss concretely the merits of one approach over another (and others), and then use these as practical examples from which we can start developing supporting APIs.

Notes 1: The MS UDDI Services schema [1], descriptive text [2], and value set files [3, 4] are available for download from Microsoft. This does not constitute an IP contribution on my part as I clearly have no right to do so; I’m simply making reference to material available to the public on the MS site. Please note that these files are copyrighted by Microsoft with all rights reserved.

 

Notes 2: The OWL schema I toyed with is likely full of errors as I could not obtain adequate tooling. I’d gladly accept input and help from OWL experts (Katia, Massimo????). What I’m providing will probably suffice for the purpose of our discussion at the FTF. We may also possibly leverage it as part of semantic search discussions - once a requirements document is submitted and its requirements prioritized.

OWL Schema Description

The OWL schema I created is contained in the “valueset.owl” file (attached). To the best of my current understanding of OWL, it limits itself to OWL-Lite.

 

The schema defines two classes: a valueSet class and a vsEntry class. The valueSet class has a set of properties including: 1) a name, 2) a description or 3) a choice of {tModelKey, tModel}. The idea of having either tModel or tModelKey is to allow the ability to load a value set along with its associated tModel definition (useful in bulk import cases), or the value set and a reference to a pre-existing tModel (useful to update existing value sets). Note that I did not figure out how using OWL Lite I could express a choice of {tModel,tModelKey}; its one or the other, not both that are intended to be allowed.

 

The vsEntry class defines a triple of: value (i.e. keyValue); title (i.e. keyName); and parentValue (i.e. of the hierarchical parent’s ID – typically a keyValue). OWL allows extending this set of properties by subclassing the vsEntry class; using this technique, the “isValid” attribute used in the MS Schema for example could be added as a property of a class derived from vsEntry. 

 

You should note the following:

  1. The OWL-version of the MS MapPoint value set has a title element that can be expressed in multiple languages (i.e. French and English in the example provided); this approach may help our I18N requirements
  2. Note that in the case of the rdf:ID attributes used for the MS MapPoint and MS Business Classification schemes are numeric which does not conform to allowable usage of rdf:ID. It is an open issue what to recommend to use as ID attribute values. Perhaps we should recommend a concatenation of xxx (e.g. a tModelKey) and the vs:value element.
  3. I have not demonstrated equivalencies (e.g. ISO3166’s “ca” country value as equivalent to that of MS MapPoint’s “someNumber” value for Canada), though OWL would allow us to do so.

I’d like to reiterate that the purpose of this mail is to help discussion of this very important topic before us. I hope this material can be of some use to us next week at the FTF.

 

Luc

 

NB: I’d appreciate some assistance on the OWL schema.

 

[1] Microsoft Extensions Schema, http://uddi.microsoft.com/extension.xsd

[2] Traversing the Tree: Using the get_relatedCategories API in UDDI Services, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnuddi/html/travtreeuddi.asp

[3] Microsoft Business Capabilities Classification Scheme, http://go.microsoft.com/fwlink/?LinkId=16851

[4] Microsoft MapPoint Geographic Context Hierarchy, http://go.microsoft.com/fwlink/?LinkId=16852

 

 

unspsc_style1.owl



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