Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel

On Feb 28, 2009, at 8:53 AM, Ben Adida wrote:
> There's an implication in your statement that @rel is a place where  
> one
> expects a URI. That's not how @rel was spec'ed to date, and I don't
> think that's been the case in most ad-hoc implementations either.

It has been discussed periodically ever since 1996, when pre-RDF
discussions concluded that properties had to be URIs.  It has been
specified in the only relevant standard to be completed since 1999,
namely Atom.

I know what the syntax issues are and the history of the specs.
For example, look at
<http://ksi.cpsc.ucalgary.ca/archives/HTML-WG/html-wg-95q1.messages/ 
0794.html>
or
<http://www.w3.org/mid/B87388E5-FDB3-471E-8E2A-4E9000C973F6@gbiv.com>

> Dublin Core is an early user of @rel, and the values they recommend  
> are:
> dc.title, dc.creator, ... In other words, things that look a lot like
> prefixed values, only without extensibility.
>
> OpenID also suggests openid.server, openid.delegate, ... Again,  
> prefixed
> values where the prefixes are assumed to be drawn from some bucket in
> the sky, so no extensibility.
>
> eRDF uses schema.dc, schema.foaf, ... again a number of non-URI  
> prefixed
> values.

All of those use a syntax that does not conflict with flat names and
URI schemes.  As such, they are extensible, as should be obvious by
the fact that they were introduced without impacting one another.

The URI, for those that need one, is defined relative
to the registry (wherever that may be), and thus ":" already has
a defined meaning within rel values to indicate "this is an absolute
URI".  The decision to do that was specifically to support RDF
properties and the general belief that all important resources in
Web architecture should be identified by URIs.

The rel values are *not* specific to media types.  They are part
of the linking model for the entire Web.  The reason there isn't
some grand specification on link relations is because it is an
architecture-wide concern and the W3C doesn't seem to be able
to sustain such an effort outside the TAG (which itself is
constrained to not act like a WG).  See, for example

http://www.csd.uwo.ca/~jamie/.Refs/LinkTypes/
http://www.w3.org/Architecture/NOTE-link.html


> The only thing we did with RDFa was to try to formalize this use of  
> @rel
> and make it extensible by providing a way to define these prefixes in
> the markup and map @rel values to URIs. We used a syntax that wouldn't
> interfere with the existing ad-hoc uses such as dc.creator and
> openid.server, while still being familiar to folks as a prefix
> mechanism, thus dc:title.

That makes no sense.  A syntax that wouldn't interfere with the existing
ad-hoc uses would be dc.title -- it doesn't change meanings just because
you give the ad-hoc syntax a standard.  Nobody would have complained  
about
using cc.whatever names with or without the attribute that says they
correspond to some other URI.  The flat registry would include them
as flat names, the RDF world would use them as URIs, and authors would
just continue to not care either way.  In fact, the only possible way
to screw with the state of the universe in link relations as decided
by past W3C and IETF working groups is to introduce something insanely
stupid like CURIEs.

....Roy

Received on Sunday, 1 March 2009 01:32:27 UTC