Re: RDFa Core last call comments - "have not yet caught up"

On Thu, May 5, 2011 at 3:13 PM, Jeni Tennison <jeni@jenitennison.com> wrote:
> Hi Jonathan,
>
> I'm still trying to catch up / understand the issue with the about="#me" type references in the RDFa Core 1.1 Working Draft [1]. There are two scenarios:
>
> 1. Where there is no element with an id="me" -- in this case you just have a broken link, right? There's no conflict about the semantics of the fragment because it never refers to an XHTML element.

There's no conflict now, although the authors of 3023bis want XPointer
semantics to apply to *all* fragids meaning that unrecognized fragids
(such as #me here) *must* be considered to be in error. Then we would
have a direct conflict between application/xml and the RDFa Core
examples.

The TAG did two rounds of {email; F2F; action; message to 3023
editors} last year. Here's a link to the message from the second
round.

http://lists.w3.org/Archives/Public/www-tag/2010Nov/0078.html

Unfortunately this happened before anyone on the TAG knew that RDFa
Core was going to happen.

In any case, the main problem is not with conflict, it's with
conformance to the specs, 3986 and the media type registrations in
particular.

> 2. Where there is an element with an id="me" -- in this case *if you get the HTML* then the #me refers to that element but you might get another representation (eg RDF/XML) as the result of conneg which either (a) doesn't have any such fragment or (b) has such a fragment but meaning something different.
>
> There are a number of examples of the first in the RDFa WD, but don't see that it's a problem -- it's not as if all fragment identifiers *must* be resolved, is it?

You are right that it is not a practical problem, and I think I said
as much on the call. It is only a problem of agreement with what the
specs say about what URIs mean.

> Regarding the second, the only example in the RDFa WD that I can see is:
>
> ---
> <html profile='http://www.example.org/vocab-rdf-dc.html'>
>  <head>
>    <title>On Crime and Punishment</title>
>    <base href="http://www.example.com/candp.xhtml" />
>  </head>
>  <body>
>    <blockquote about="#q1" rel="dcterms:source" resource="urn:ISBN:0140449132">
>      <p id="q1">
>        Rodion Romanovitch! My dear friend! If you go on in this way
>        you will go mad, I am positive! Drink, pray, if only a few drops!
>      </p>
>    </blockquote>
>  </body>
> </html>
> ---
>
> Is this the particular example in the spec that's caused concerns to the TAG?

No. The example is
<div vocab="http://xmlns.com/foaf/0.1/" about="#me">
because RFC 3023 does not tell you how to interpret the 'me' fragid in
a way that will give the correct answer for RDFa. (Obviously, since it
was written before RDFa was invented.)

(The RDFa #me would work perfectly well *if* there were an RDF/XML or
Turtle representation of the same resource containing the same RDF
statements, and 3023bis were not put into effect; but that's not what
is being considered. We can assume there is only one representation,
say application/xml.)

The issue is how FYN works. Perhaps 3986 is open to interpretation,
but I think the way I've been reading it is, in caricature:
  - To find out what secondary resource is "identified" by A#B:
  - Get all current representations of A (or as many as you can get
ahold of, or at least one of them)
  - For each representation, consult the media type reg
  - The media type reg tells you how to parse the document and how to
figure out what the doc says about fragid meaning
  - Unify the information for #B coming from all A representations
that constrain #B, merging to obtain (if all goes well) a consistent
idea of what the secondary resource is.

There is no way to get from this FYN story to any hint of what the #me
URI is supposed to 'identify'. The media type registrations for html
and xml do not tell you that you should read the document's RDFa and
take those triples to information - any more than the registration for
text/plain tells you that a natural language sentence explaining what
a particular fragid means has to be recognized as authoritative
(w.r.t. FYN) for what it means.

Now this FYN story is almost certainly wrong, but if so, somebody
needs to step forward with a substitute, and either change 3986, or
explain why we've been misinterpreting 3986 all these years. Or else
explain why there is no need for FYN.

What I said on the call today is that there seems to be pressure in
the RDF community to divorce the RDF URI namespace from the IETF (3986
etc.) namespace - i.e. to say it's fine for a single URI to "identify"
different things in the two worlds. (Maybe there are two different FYN
algorithms, maybe "refer to" and "identify" are different, etc.)
Having two bindings for each URI is clearly not consonant with the
one-web ideal or the original aim of RDF to record lots of information
about the Web, and the TAG rejected the split in 2005 when it came up.
Again, this may or may not be a good design, but it's really no good
for the two-namespace design to get a foothold by accident. If it's a
serious proposal it should be put forth as an one and evaluated.

Another comment on the topic of fragids...

We talked briefly about what if a URI has two zzz+xml representations,
and one repr. has <foo id="x"> and another has <bar id="x">. 3023 says
that "x" identifies an element. Elements have types. So what is the
type of the element #x, "foo" or "bar"?  It simply can't be both. This
3986 business about "consistency" is fine as far as it goes but there
is no consistent way to have a single element that has two types.
There are many ways to fix this; I'm just whining that if you take the
specs at face value, you get something that makes little sense and
that no one either wants or respects.

If you don't believe me, we can go through them with a fine-tooth comb
together...

Jonathan

> In this case, the RDF statement is:
>
>  <http://www.example.com/candp.xhtml#q1> dcterms:source <urn:ISBN:0140449132>
>
> The syntax of the URI in this case makes me believe that it is not a conneg'd resource: it seems to be pointing directly to an XHTML document, which means the fragment would always reference that particular paragraph and the RDFa statement is (I think very deliberately) about that paragraph. Would it help in this case to have an explanation after that particular example that states this?
>
> Cheers,
>
> Jeni
>
> [1]: http://www.w3.org/TR/2011/WD-rdfa-core-20110331/
> --
> Jeni Tennison
> http://www.jenitennison.com
>
>

Received on Thursday, 5 May 2011 21:20:10 UTC