ACTION-502: RDFa and fragid semantics

Re ACTION-502: Report back on discussions with Ben Adida regarding
fragid semantics for RDFa

Background: RDFa documents define fragment ids in XML and HTML
documents using the syntax 'about="#xyz"'.  While this pattern is not
explicitly called out in any RDFa recommendation or draft, it is used
in many examples in recommendations and rec track documents (see [1],
[2]).  It is also widely used in practice [citation needed].

According to RFC 3986, a "fragment's format and resolution is
... dependent on the media type of a potentially retrieved
representation".  However, the media type registrations that would
apply to documents in which RDFa occurs do not explain this practice.
Thus actual RDFa practice appears to be outside the chain of
specifications.

I spoke with Ben Adida, RDFa WG co-chair, about this situation.

Ben confirmed my sense that this use of fragids is an important part
of the RDFa value proposition, and that it is widely deployed.
Deprecating the practice at this point would be extremely disruptive.

He said it was the working group's sense that nothing in particular
needs to be done to enable this mode of fragid definition, and that it
worked just fine.  Their solution is to do nothing.

If a fix is deemed necessary, there are multiple possible intervention
points, including: deprecating the practice, revising 3986, revising
AWWW, and revising the relevant media type registrations.  The latter
seems easiest as revisions to both registrations are currently
under preparation.

The RDFa WG has no plans to take up this issue or to request any
changes to the relevant media type registrations.

[Note that this is *not* a problem for application/rdf+xml, as its
media type registration *does* address the question.]

Best
Jonathan

[1] RDFa in XHTML: Syntax and Processing
http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014
section 6.1.1.1, etc.

[2] RDFa Core 1.1: Syntax and processing rules for embedding RDF
through attributes
http://www.w3.org/TR/2010/WD-rdfa-core-20101026/
section 8.1.1.1, etc.

Received on Monday, 29 November 2010 20:55:52 UTC