- From: Dan Brickley <danbri@w3.org>
- Date: Mon, 14 Jul 2003 04:32:55 -0400
- To: Jacek Kopecky <jacek@systinet.com>
- Cc: Rich Salz <rsalz@datapower.com>, "Agarwal, Naresh" <nagarwal@informatica.com>, "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Hi there * Jacek Kopecky <jacek@systinet.com> [2003-07-14 10:11+0200] > Dan, while I don't really see the connection between SOAP Data Model and > RDF or the value of SOAP Encoding in relation to RDF, but I still think > SOAP Data Model and SOAP Encoding are valuable for data that is not > easily and naturally representable by trees. Yup, I find RDF valuable for similar reasons. They basically have the same abstract graph data model, although have rather different origins and expectations surrounding their use. And different XML encoding syntax. > > I see the biggest value of SOAP Data Model and SOAP Encoding in being > able to communicate the graph structure of data interoperably. To this > end it is necessary to have a way of describing a graph schema, which > I'm working on in the background. Interesting - I'd be interested to see that work happen in the foreground ;) Would a "graph schema", in your sense, define classes of graph-based XML document? Or would it provide metadata about the node and edge types that can appear in such documents? FWIW RDF's vocabulary description languages (RDFS and now OWL too) are in the latter category. They don't define classes of document in terms of their necessary and sufficient conditions; instead, they say things like 'the author relationship always links a Document to a Person'. My hunch is that your 'graph schema' language for SOAP Encoding would say things like "when you see an 'author' edge in the graph, the node it points to should always be indiciated to be of type 'Person'." An RDF Schema, by contrast, would just say "Whenever you see an 'author' edge in the graph, the thing it references will be a 'Person' (regardless of whether the actual XML bothers to include that information". Another possible difference is RDF's open world / extensibility assumptions. In RDF, the agency defining a class such as 'Person' does _not_ get to have the final say on what properties are allowed on instances of that class. To make this real, here's a real example. I have an RDFS/OWL schema which defines a class, foaf:Person in the namespace http://xmlns.com/foaf/0.1/ (view src there to see the RDF if curious). This schema, in effect, says "some but not all things in the world are of type foaf:Person; here are some facts about the class foaf:Person", and goes on to list _some_ properties which apply to people. However being RDF, we always have to allow possibility of instance data using additional vocabulary, attaching more properties to Person instances. So, for example, see http://kota.s12.xrea.com/vocab/uranai/ for another RDF vocabulary (at a different namespace) which declares more properties of people, ie. properties with an rdfs:domain of foaf:Person. In this case, properties such as 'bloodtype' and 'starsign' which were not anticipated in the original schema. That's pretty typical of the way people deploy things with RDF. I would like to better understand how things could work for SOAP Encoding, whether we could see the same open world approach to extensibility, or whether people are making more traditional OO assumptions, eg. that a SOAP graph schema (if these existed) for xyz:Person could enumerate all the properties that were allowable on 'Person' nodes in the graph. With SOAP Encoding, what do people typically do about namespaces? Are there shared 'soap encoding' namespaces which are seeing any amount of cross-application re-use? Hope this is making some sense, Dan
Received on Monday, 14 July 2003 04:32:55 UTC