- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Tue, 5 Mar 2002 10:27:50 -0500
- To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>, "www-webont-wg" <www-webont-wg@w3.org>
Jeremy Carroll wrote: Let me clarify (long but significant points are made throughout so bear with me) > > I think there are three issues here and I would like to separate them: > > 1: was rdf:parseType="daml:collection" a good idea? Does it need blessing? Issues 1 and 3 are really the same. My assumption is that the DAML community felt the need for a better way to express lists. If this is the case, that is to say, if RDF collections don't cut it, then _some_ mechanism is needed. rdf:parseType="foo" appears to be an easy extension mechanism. My argument is that while it may be, it comes with significant costs which are charged against the benefits of using RDF in the first place. > > 2: how does rdf:parseType="Literal" interact with RDF and OWL? This is a different issue. Clearly the ability to deal with XML datatypes is important for OWL, and what RDFCore comes up with has great pertinence. The particular issue I am raising has to do with use of rdf:parseType="foo" (which is essentially the same as -- from the RDF parser perspective -- rdf:parseType="Literal" ) as a mechanism of embedding parts of the OWL language as XML within RDF. You see this just doesn't cut it if we intend the RDF MT to be related to the OWL MT in a meaningful way. This practice is akin to the well known practice of embedding proprietary extensions to a programming language within comments. ***When this changes the set of machine instructions emitted, it is a very bad practice ***. In such cases it is better of to create a new language and call it such. Much as the relationship between Java and C#. > > 3: is rdf:parseType="foobar" a sensible extensibility mechanism which OWL > can live with. right. this is the question. and if OWL cannot otherwise live with RDF, then we have some hard decisions to make. > > > I am unclear which of these Jonathan is addressing, it appears to be (2), I > will add an in-line comment on Jonathan's example on that basis. It is 3 > > === > > My take is: > 1: don't know > 2: see RDF Core > as long as RDF core improves the defn of xml literals, to include at > least equality, I don't see any deep issues > 3: no this is not a good extensibility mechanism > (There appeared to be agreement at the RDF Core f2f on that issue - in > particular the "foobar" did not make it into the RDF graph). Here we are on the same page. The specific question for OWL as an adoption of DAML is then: what to do with "daml:collection" and similarly for N3: what to do with rdf:parseType="log:quote" _both_ of which I think are essential facilities to have. > > A trivial example: > > > > <rdf:RDF> > > <rdf:Description rdf:about="this"> > > <ex:ontology rdf:parseType="Literal"> > > <expr> > > <forall var="x y z"> > > <or> > > <x/> > > <y/> > > </or> > > <implies/> > > <z/> > > </forall> > > </expr> > > ... > > </ex:ontology> > > </rdf:Description> > > </rdf:RDF> > > > > the point being that one can create a perfectly 'legal' RDF > > document, which > > through the use of rdf:parseType="Literal" embeds _some other language_. > > > > What is the point of that? > > It is useful, for example for embedding well-known markup languages such as > xhtml within RDF, or ruby or mathml as in the example at the end of M&S. OK, > RDF and OWL processors don't understand such markup, but then they do not > understand the internal content of string literals either (modulo > datatyping). This is correct. But what I am doing here is embedding a forumla within the XML, and this formula is something that might be of interest to OWL as a formula, not merely a piece of XML data. This practice is analagous to LISP s-expressions as code/data. In fact the comparision between s-expressions and XML is straightforward. A simple example: The data model of XML is described in the XPath data model which has the "NodeList" as a primary datatype. Thus the conversion between an s-expression and XML and vis versa is easy. For example: (or a b c d) => <or> <a/> <b/> <c/> <d/> </or> The so-called redundancy of the trailing element end tag (ETag) i.e. "</or>" has been widely discussed. Good reasons for its inclusion are: 1) Humans are better at parsing complex statements when ETags are present. 2) ETags greatly facilitate the manipulation of expressions using Regular Expressions In any case XML and s-expressions co-exist very nicely -- in fact the precursor to the XSLT transform language was DSSSL which was based on Scheme and used the s-expression syntax, so the relationship between the s-expression and XML data models is no coincidence. > > > > > i.e since you need a specialized application in order to understand the > > embedded language, what is the benefit of encapsulating it in RDF? If only > > to help us along the way to writing parsers, query languages etc, the RDF > > parsers and query languages won't help, because the the parsers won't > > understand the embedded language > > OVERSTATED: the RDF parser will be able to understand the XML, just not the > language specific features. Not overstated, if _language specific features_ are embedded as XML in literals, the RDF parsers won't understand them. An OWL parser would have to parse the XML itself. > > > and the query language won't be able to > > inference -- > > OVERSTATED: the QL will be able to do inference based on the XML Literal as > a piece of XML. It does need equality to be well-defined over XML Literals; > RDF Core will deliver that in the next week or two. Again, when XML in Literals is used as a part of the OWL _language_ the XML is not being used only as a piece of XML. This is highly relevent. What about N3's use of "log:quote"? Does any base RDF parser understand the implications of that? ... > > > we would be better off hacking together an XML based > > parser (a > > rather easy task when the language is properly designed) and using XQuery > > with an add on library. > > The embedding markup use case will not go away. And your proposed solution > will suffer from it in a similar fashion. There are RDF users who have mixed > language strings, bi-directional strings. The rdf:parseType="Literal" > mechanism currently allows these issues to be addressed; if we start from a > blank sheet we will still need something equivalent. > > (Of course, the syntax could be improved!) > I am not necessarily suggesting that we start from a blank sheet, rather that we properly understand the implications of using rdf:parseType="foo" as an extension mechanism. It has significant effects on the layering issue. That said, I could come up with a few simple changes to the RDF syntax which would likely solve the problems. Unfortunately they are not within the scope of what RDFCore is currently working on. For example: 1) Introducing "contexts" into the syntax as a way to declare non-asserted triples. 2) Introducing "lists" into the RDF MT (i.e. order) and a corresponding recursive syntax Jonathan
Received on Tuesday, 5 March 2002 09:49:45 UTC