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] Examples of Value Set Representations - OWL andMicrosoft's Extensions Schema


John,
 
+1
 
The only thing I disagree with is the use of Category/Identifier Bag structure. It is too restrictive. The metadata part can be hierarchical in many cases. I discussed this point in my docos.
 
Consider this real life analogy about this semantics:
Semantics - metadata (what is attached to an object) and ontology
Cognition - information (what I see looking at an object) and knowledge
 
Putting those 2 together helps to make a coclusion
 
Assume that there are dozens of tModels for wine. One of them has an RDF-bag like this
 
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:vin="http://www.w3.org/TR/2003/PR-owl-guide-20031209/wine#">
     <vin:VintageYear>Year1998</vin:VintageYear>
     <vin:WineGrape>CabernetSauvignonGrape</vin:WineGrape>
     <vin:Winery>Corbans</vin:Winery>
</rdf:RDF>
This is what I know about the wine I'm looking for
<WineColor>White</Wine>
<Region>Mendox</Region>
 
I give it to a semantic engine that uses this ontology
 
The semantic engine will use the RDF bag as "information" and the ontology as "knowledge".
The result will be a list of wines that are white and made in that region. At the same time the color and the region are not part of the RDF bag, but still can be inferred using the ontology.
 
Look at the RDF bag example now - do u think that wine will be returned too? Exactly! You can say so because of your background knowledge (sort of grape and winery name).
The semantic engine will use the ontology as the knowledge base and follow a process similar to the cognitive process you went thru before making your conclusion on the wine suitability.
 
Cheers,
Max
 
 
----- Original Message -----
Sent: Friday, 6 February 2004 23:38
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

 

 



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