Re: parseType="daml:list" doesn't cut it

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