Re: RDF Concepts and fragids

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.)

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".

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.

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

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.

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.

Jonathan

On Fri, Apr 1, 2011 at 7:10 PM, Nathan <nathan@webr3.org> wrote:
> Jonathan Rees wrote:
>>
>> Poking around the blogosphere I came across this:
>>
>> http://www.w3.org/TR/rdf-concepts/#section-fragID
>>
>> which seems to contradict 3986 and webarch.  According to this text,
>> if I have id="foo" in an XML document (not rdf+xml) at
>> http://example/x, then http://example/x does NOT refer to that XML
>> element, as it would according to 3986 and webarch.
>>
>> Worse, if there's RDF at that URI published as Turtle, then the Turtle
>> can't specify the meaning of a fragid, because Concepts says that
>> RDF/XML semantics applies.
>>
>> What a rathole!
>>
>> Nathan, I trust you'll be fixing this. Somehow. :)
>
> Thanks for that!
>
> RFC3023, XML media type [ http://www.ietf.org/rfc/rfc3023.txt ] says:
>
>   Section 4.1 of [RFC2396] notes that the semantics of a fragment
>   identifier (the part of a URI after a "#") is a property of the data
>   resulting from a retrieval action, and that the format and
>   interpretation of fragment identifiers is dependent on the media type
>   of the retrieval result.
>
>   As of today, no established specifications define identifiers for XML
>   media types.
>
> (so undefined)
>
> RFC 3986, URI [ http://www.ietf.org/rfc/rfc3986.txt ] says:
>
>   The fragment identifier component of a URI allows indirect
>   identification of a secondary resource by reference to a primary
>   resource and additional identifying information.  The identified
>   secondary resource may be some portion or subset of the primary
>   resource, some view on representations of the primary resource, or
>  *some other resource defined or described by those representations.*
>
> (so it can be anything defined or described by)
>
> RFC 3870, RDF media type [ http://www.ietf.org/rfc/rfc3870.txt ] says:
>
>   The rdf:ID and rdf:about attributes can be used to define fragments
>   in an RDF document.
>
> (which defines rdf:ID and rdf:about as defining attributes, not @id)
>
> and http://www.w3.org/TR/rdf-concepts/#section-fragID says:
>
>   eg:someurl#frag means the thing that is indicated, according to the
>   rules of the application/rdf+xml MIME content-type as a "fragment"
>   or "view" of the RDF document at eg:someurl. If the document does not
>   exist, or cannot be retrieved, or is available only in formats other
>   than application/rdf+xml, then exactly what that view may be is
>   somewhat undetermined, but that does not prevent use of RDF to say
>   things about it.
>
>   the RDF treatment of a fragment identifier allows it to indicate a
>   thing that is entirely external to the document, or even to the
>   "shared information space" known as the Web. That is, it can be a
>   more general idea, like some particular car or a mythical Unicorn.
>
> (which on my read, is aligned with URI and web arch).
>
> So, Turtle isn't a rec w/ a mime type yet, and when it does it'll define
> things inline w/ RDF, URI and Web Arch. XML doesn't define @id as being for
> fragments (that I can see), so unsure what the issue is? (other than
> brushing up on wording and references to related specs).
>
> Best,
>
> Nathan
>

Received on Saturday, 2 April 2011 14:19:43 UTC