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

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?

2: how does rdf:parseType="Literal" interact with RDF and OWL?

3: is rdf:parseType="foobar" a sensible extensibility mechanism which OWL
can live with.


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.

===

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).






>
> 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).

>
> 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.

>                                  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.

In your example, the whitespace appears insignificant. In some other XML,
e.g. poetry, the whitespace may be significant. Hence the equality of XML
Literals will have to be sensitive to whitespace, and the following differs
from your example:
<ex:ontology rdf:parseType="Literal">
<expr><forall var="x y z">
<or><x/><y/></or><implies/><z/>
</forall></expr>...</ex:ontology>

but that seems to be no different from saying that "blue " and "blue"
differ. It might not be the user intent, but at least its clear.

>               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!)


Jeremy

Received on Tuesday, 5 March 2002 05:43:52 UTC