W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2001

about literals

From: Stefan Kokkelink <skokkeli@mathematik.uni-osnabrueck.de>
Date: Mon, 05 Mar 2001 17:15:21 +0100
Message-ID: <3AA3BB99.4B570063@mathematik.uni-osnabrueck.de>
To: RDF interest group <www-rdf-interest@w3.org>
CC: Art Barstow <barstow@w3.org>, Aaron Swartz <aswartz@upclink.com>, Dave.Beckett@bristol.ac.uk
Art Barstow wrote:

> If you disagree with me, then I suggest you raise it on
> rdf-interest and get it on the RDF issue list:
>  http://www.w3.org/2000/03/rdf-tracking/

ok, here it goes: how is the following XML
expected to be parsed by an RDF processor:

<?xml version="1.0" ?>
<rdf:RDF xmlns="http://www.w3.org/HTML"
   <rdf:Description about="John_Smith">
    <my:Name rdf:parseType="Literal">

CARA creates the following literal respecting the
given namespace information:

l('<html:h1 xmlns:html="http://NoHTML">
     <b xmlns="http://www.w3.org/HTML">John</b> 

Art said:

> My take on the following part of the spec:
>   The value 'Literal' specifies that the element content is to be
>   treated as an RDF/XML literal; that is, the content must not be
>   interpreted by an RDF processor.
> is that the RDF processor should do *nothing* with the content of
> a propertyElt with parseType="Literal".  That is, I would expect
> the object to be the string to be unmodified:
>        <html:h1>
>          <b>John</b>
>        </html:h1>

My interpretation of the spec is different: The serialization format of
RDF is XML and therefore must be processed as XML, that is, a processor
has to respect the given namespace information. Otherwise we get 
incorrect information as in the example above. My interpretation
of "that is, the content must not be interpreted by an RDF processor"
is that a processor is not allowed to produce triples, but is allowed
to choose a (equivalent) serialization of the XML subtree specified by 
the literal.

However, it would be nice if this could be clarified by
RDFCore ...

Received on Monday, 5 March 2001 11:15:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:34 UTC