Re: Possible solutions for ISSUE 97

Hi Ivan,

I'm afraid the logic is getting very convoluted!

I said:

>  > First, I don't agree that there are many different serialisations
>  > possible of the same graph.

You replied:

> Mark, I think you are wrong on that point.

but as proof, you simply reasserted the original point:

>  Note entry #2. This means that if one has two different serializations
>  with XML Literals (like the ones provided by Ben)...

Ben didn't give us two different serialisations of an XML literal, he
just gave us some made-up mark-up. If the abstract graph is in
exclusive canonicalised form, by what process do we end up with a
serialisation that includes extra namespace declarations in child
elements? (That is what Ben's second 'serialisation' has.) In other
words, given one particular Exclusive Canonicalised Form, we end up
with one graph, not any graph we choose.


You then went on:

> ...when Exclusive
>  XML Canonicalization is applied, lead to the same lexical form, then the
>  two serializations express exactly the same RDF graph.

Again, you are mixing up layers. Why would you apply canonicalisation
to the serialisation of the abstract graph? Canonicalisation is what
defines the value in the abstract graph itself.

I think, what you and Ben are trying to do is to say that, since in
some implementation we can normalise the data (canonicalise) at some
later point in the workflow, therefore we don't need to normalise when
creating the RDF graph. But if we have to canonicalise to create the
graph, then that doesn't work. Obviously it works fine in the closed
world of an implementation, but it doesn't work in defining the
specification.


>  Again: _you are absolutely right_ that an RDFa to abstract RDF processor
>  must perform the canonicalization, just as the RDF/XML describes it!

And that is all we can discuss, I'm afraid...that's why we have the
whole section on RDF.


> But
>  what I am saying and, I think, what Ben is saying is that this is
>  inconsequential to RDFa implementations that produce, say, RDF/XML or
>  Turtle, because the abstract RDFa->Graph machine is then a combination
>  of two engines: the RDFa->RDF/XML translator and the RDF/XML parser to
>  whatever RDF implementation you choose.

First, that does not help in the *definition* of RDFa, since it needs
to be in terms of the abstract graph.

And second, you are still assuming that there can be two
serialisations of the same graph, which as I pointed out above you
haven't yet proved.


> And none of the RDF
>  serializations syntaxes in use require the user to use canonicalization.

My reading of RDF Concepts is that you need to canonicalise in order
to create the abstract graph.


>  And that means that the changes on the syntax document are marginal and
>  only require explanations, and the change on the SPARQL test is again
>  marginal.
>
>  Ie: I simply do not believe we really have a major problem here!

I really fee like we're wishing the problem away. XML literals have
been an annoying pain in RDF for a long time, and they are biting us
now. (Actually, the problem is XML namespaces, but that's another
story.)

Regards,

Mark

-- 
  Mark Birbeck

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.x-port.net | http://internet-apps.blogspot.com

  x-port.net Ltd. is registered in England and Wales, number 03730711
  The registered office is at:

    2nd Floor
    Titchfield House
    69-85 Tabernacle Street
    London
    EC2A 4RR

Received on Thursday, 20 March 2008 11:57:13 UTC