W3C home > Mailing lists > Public > semantic-web@w3.org > March 2008

Re: Possible solutions for ISSUE 87

From: Ivan Herman <ivan@w3.org>
Date: Thu, 13 Mar 2008 16:20:13 +0100
Message-ID: <47D9462D.4050705@w3.org>
To: Mark Birbeck <mark.birbeck@x-port.net>
CC: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>, Semantic Web <semantic-web@w3.org>, "Jeremy J. Carroll" <jjc@hpl.hp.com>
Ah! O.k., so we are closer to one another's opinion! But it helps to 
clarify the issue and it may be, after all, an editorial one... Because...

- As we define the RDFa parser in terms of producing an RDF graph then, 
yes, the RDF Concept document applies. With canonicalization and all 
that jazz. But I am not even sure that is part of the RDFa syntax 
document; a reference to the concept document suffices.

- However, an implementation of RDFa that produces an RDF graph in some 
other serialization (which is the case for a number of our 
implementations, though probably not all; it certainly true for Fabien's 
xslt script, my stuff, probably Manu's code) has to produce a *valid* 
serialized version of the RDF graph.

So, suddenly, I am lost:-( Where is the problem? Remember that the issue 
started with Johannes' pertinent mail[1]:

[[[
Hi,

the sparql query for test case 0011 
(<http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0011.sparql>) 
contains the triple

<http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0011.xhtml> 
<http://purl.org/dc/elements/1.1/title>
"E = mc<sup>2</sup>: The Most Urgent Problem of Our Time"^^
   <http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .

In the test file 
(<http://www.w3.org/2006/07/SWD/RDFa/testsuite/xhtml1-testcases/0011.xhtml>) 
the sup element is in the http://www.w3.org/1999/xhtml namespace. 
Shouldn't this be included somehow in the object literal?
]]]

and the answer to Johannes' mail is simply: yes! Isn't it all?

Ivan

[1] http://www.w3.org/mid/47CD5C94.1020704@w3development.de

Mark Birbeck wrote:
> Hi Ivan,
> 
> (And semantic-web@w3.org!)
> 
>>  I am afraid I diverge a bit with your analysis, although I agree that we
>>  have to be a bit loose in the final specification.
> 
> Ok.
> 
> 
>>  You refer to the RDF Concept document which, indeed, refers to the XML
>>  canonicalization.
> 
> Right...after all, that's the only document we refer to in the spec,
> and it's the only document of relevance for a new serialisation of
> RDF, which RDFa is.
> 
> 
>> However... let us look, for example, at the RDF/XML
>>  document[1]. Note that the section on XML Literals does *not* say that
>>  the XML Literal *in the RDF XML serialiation* must be canonicalized.
> 
> But why would it? You only normalise after parsing.
> 
> 
>>  Actually, the example in that very section:
>>
>>  <?xml version="1.0"?>
>>  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>           xmlns:ex="http://example.org/stuff/1.0/">
>>    <rdf:Description rdf:about="http://example.org/item01">
>>      <ex:prop rdf:parseType="Literal"
>>               xmlns:a="http://example.org/a#"><a:Box required="true">
>>           <a:widget size="10" />
>>           <a:grommit id="23" /></a:Box>
>>      </ex:prop>
>>    </rdf:Description>
>>  </rdf:RDF>
>>
>>
>>  is not doing this either, because the namespace definition for 'a' is
>>  _not_ on the XMLLiteral portion but the 'enclosing' XML element (which
>>  represents a predicate and is not part of the XML Literal object).
> 
> But this is the mark-up, not the RDF. You have to turn this into an
> rdf:XMLLiteral.
> 
> 
>>  What the document says is that *when the encoding is transformed into an
>>  RDF Graph*, then the canonicalization must be performed. Look at section
>>  7.2.17 of the grammar production rules[3] which essentially says that.
>>  Ie, the RDF/XML parser, seeing the code above, must produce an XML
>>  Literal with the lexical part being:
>>
>>  <a:Box xmlns:a="http://example.org/a#" required="true">
>>           <a:widget size="10" />
>>           <a:grommit id="23" /></a:Box>
>>
>>  (note the namespace declaration that has been moved 'down' to the
>>  <a:Box> element.)
> 
> I know. :) What are you telling me?
> 
> 
>>  What this means is that if my RDFa parser produces an RDF/XML output,
>>  the only thing I have to make sure is that all namespaces *are* defined
>>  somewhere on the RDF/XML tree, so that an RDF/XML parser would be able
>>  to to a proper job in the canonicalization.
> 
> That's up to you, Ivan, in that you are entitled to do whatever you
> like with your parser. But the output of an RDFa parser is not
> RDF/XML, but an RDF graph.
> 
> 
>> One way would be to say that
>>  we 'dump', as you say, all the namespace information to all the top
>>  level nodes of an XML literal. But, in fact, if I don't do anything
>>  except adding the xhtml namespace on the rdf:RDF level, too, this would
>>  also be perfectly acceptable.
> 
> It's no good, I'm afraid, Ivan. You can't solve the problem in one
> serialisation of RDF by saying that you are going to convert it to
> another serialisation of RDF; the output from an RDFa parser is an RDF
> graph, not RDF/XML.
> 
> 
>> Hence a certain looseness in the way we
>>  would define this thing... But I do not think the canonicalization
>>  algorithm is supposed to be applied on that point.
>>
>>  The problem occurs when an RDFa implementation produces directly an RDF
>>  graph. Then, of course, somebody along the line must perform the
>>  canonicalization. But that, in some ways, another matter.
> 
> Ah...ok...
> 
> But that is the only issue that concerns us. If you convert to RDF/XML
> en route that's a bonus for you, and you've saved yourself some
> implementation hassle. But that doesn't help with the general problem.
> 
> 
>>  Now let us see what wiser people like Jeremy will tell us:-)
> 
> Yes, let's. :)
> 
> Regards,
> 
> Mark
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Thursday, 13 March 2008 15:20:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:03 UTC