Re: RDF Concepts and fragids

Jonathan Rees wrote:
> Very little of this is relevant. (I might point out that 3023 is under
> revision, that the RDF WG will be the one submitting the Turtle
> registration (right??), and that text/n3 has been recently resubmitted
> to IETF. But none of this bears on the example since you get the
> failure for *any* media type other than application/rdf+xml.)

aside: I think turtle was submitted too tbh (Eric and I prepared them 
both), unsure if the IESG reviewed both or just text/n3 though, waiting 
to hear back. If not though, then yes surely we'll be registering a 
media type for turtle over the course of the RDF WG.

> Suppose http://example/doc yields an HTML document containing <a
> name="foo">. RFC 2854 has
> 
>    For documents labeled as text/html, the fragment identifier
>    designates the correspondingly named element; any element may be
>    named with the "id" attribute, and A, APPLET, FRAME, IFRAME, IMG and
>    MAP elements may be named with a "name" attribute.
> 
> But RDF concepts says
> 
>    a URI reference in an RDF graph is treated with respect to the MIME
> type application/rdf+xml
> 
> If you apply the RDF/XML semantics to an HTML document you get
> nonsense - the text isn't even necessarily syntactically correct,
> although even if it were the name= wouldn't apply in RDF/XML.
> Therefore according to RDF concepts http://example/doc#foo means
> nothing, while according to 3986 and webarch it means "the
> correspondingly named element".

Hmm, I read that differently, "a URI Reference in an RDF Graph", it 
doesn't speak of URIs used outwith of RDF (as in, it doesn't try to say 
they are or are not meaningless, just that you don't know the meaning in 
RDF), and when one does use such URIs in RDF, surely the URI collision 
comes in to play, such that one would write (in RDF):

  <http://example/doc#foo> a :HTMLElement .

Perhaps a bigger glitch, or should I say the only one I can see, is that 
http://example/doc would be taken to designate some RDF document, even 
when it is not an RDF document:

[[
we assume that the URI part (i.e. excluding fragment identifier) 
identifies a resource, which is presumed to have an RDF representation. 
So when eg:someurl#frag is used in an RDF document, eg:someurl is taken 
to designate some RDF document (even when no such document can be 
retrieved).
]]

> This seems like a major glitch - basically it says you can't use HTML
> fragids in FYN-compliant RDF, not even in rdfs:seeAlso - and given
> that the RDF WG is revising the concepts document (it is, right?) it's
> their responsibility to fix it, one way or the other.

Yes, I think all docs are open to being revised, and yes I agree the 
responsibility is there to fix it (unsure all would agree though!).

> I guess I could work this out with the WG but was hoping you'd take it
> up for me.

I'm quite happy to, will need feedback from yourself (& TAG) during the 
process though, probably needs a joint effort to fix the text between 
the RDF WG and RDFa WG, if the it can be done in the charter time 
overlaps that is. Although.. HTML+RDFa is on a different timeline, and 
text could go in there.

> Of interest here in AWWSW since the fragid rathole falls within our
> charter, I think. I've now seen six failures of fragid architecture
> within the last couple of months, this being just the most recent
> (3023bis vs. rdf+xml; 3023 vs. RDFa Core; 3986 vs. URNbis draft; same
> fragid in different languages; difficulty in formalizing FYN story for
> fragids; now RDF concepts vs. 3986) ... I'll plan  on writing these up
> for the TAG since there seems to be a pattern.

Would be interested on seeing that, there's also RDFa for pure XML to 
think about, so the XPointer and new frag spec for XML will need thought 
about too I guess.

> This is of importance for issue 57 because I'd like to offer some
> disciplined use of fragids as the easy-to-deploy semweb solution, and
> all of these weaknesses are threats that have to be defused in order
> for fragids to work.

Agree, it would be good just to have a simple story on this from the TAG 
which was rec track (fragid's that is), and which all these other specs 
can reference. Would that fall under the planned doc / issue 57?

Best,

Nathan

Received on Saturday, 2 April 2011 15:51:02 UTC