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

Mark Nottingham wrote:
> 
> Sorry, I should have been more clear; I'm talking about in HTML4 (since
> CC doesn't require or recommend XHTML for CC+).

Ah, got it. We (CC) are vague on this issue. Note that there is no way
for us to validate RDFa in HTML4 right now, so it's not clear what we
could do. This is very much "experimenting outside the standard".

> What's wrong with a URI (i.e., an actual, syntactic one, instead of a
> shorthand)?

Conceptually, not much. But in fact when we looked at existing uses of
@rel, we found that prefixed values were far more common, even though
the prefixes were never declared.

Dublin Core suggests using rel="dc.creator"

OpenID suggests using rel="openid.server"

eRDF suggests using rel="schema.dc"

Combine that with the saving of repetitive bytes (which is
non-negligible when you're writing your FOAF file, for example), that's
why we went this route.

> I'm concerned, but there are always going to be things working outside
> the bounds of the standards. I just want to minimise that happening
> inside standards, because then we (collectively) are giving people
> conflicting advice.

That makes sense. The RDFa task force has definitely tried to do this
while at the same time creating a syntax that was natural enough for
folks to start using.

I'll make the historical note that, when we started a few years ago,
even the idea of @rel being semantically a URI was appalling to some :)
Now it's so natural folks are questioning the more-established prefix
notation for predicates :)

> True, but AIUI that's a moving target. For the moment, my focus is on
> HTML4.

Sounds good. We have had requests from folks to "find a way" to make
RDFa work in HTML4. I'm not sure if that's possible, but it's certainly
something I'd like to explore.

[...]

> If I have two HTML4 documents in front of me, and they both have the
> profile "http://example.com/foo" and a link with the relation "bar", I
> think I should be able to assume that those links have the same
> relation.

I'm not sure that's true. Take GRDDL, for example, which specifies a
@profile that triggers general GRDDL processing, which then looks at
<link rel="transformation"> to specify the actual vocabulary-specific
transformations:

http://www.w3.org/TR/grddl/

That tuple (@profile, <link rel="transformation">, @rel) is similar to
what we have in RDFa: (RDFa flag, @xmlns/@prefix, @rel). Note that the
nature of the second element of that tuple (the element or attribute
name) depends on the first, which is the complicating factor.

[...]

> Therefore, you really do need to say *something* about HTML4 (as well as
> bare XHTML, for that matter), and provide a way to make it unambiguous.

I'm starting to be convinced about this, that we need a better story at
least for HTML4.

That said, as mentioned above, I think the complication on parser
consistency exists already.

> As I said before, 99% of the people reading that document will assume
> HTML4, and I think it's also a safe wager to say that something
> approaching that number have never heard of RDFa. Do you believe otherwise?

You're right, in fact most people won't even know about different
versions of HTML :)

> At this point, I think the most helpful thing that could be done for
> HTML4 (and I'm really only talking about it, at the moment) is to come
> up with some helpful, global (i.e., not RDFa-specific) conventions for
> reuse.
> 
> E.g., a profile URI whose semantics is "all link relations in this
> document that have a colon in them are (syntactic) URIs." That would be
> less ambiguous than what the Link appendix proposes now, and also opt-in.
> 
> I suppose if you really wanted to keep the prefix syntax, we could have
> another profile URI whose semantics were, roughly, "all link relations
> in this document that have a colon in them have a prefix defined in a
> HTML <meta> element, where the prefix is defined by the title
> attribute." Just a rough idea; IMO that's much more HTML4-friendly then
> either using xmlns or using a new attribute like profile.

Declaring the prefixes in the HEAD is a big problem for fragments, which
is a major use case for RDFa. Thus the use of attributes to declare
these prefixes.

> The more I look at it, the more I like the first profile; I'm likely to
> write that into the next draft of Link, in some form. However, we need
> to have a long, hard think about the ramifications of this second
> profile. Again, what's wrong with a bare URI? If the answer is just
> "saving bytes" it's a very poor excuse indeed.

Prefixed values is actually the far more common use of @rel so far,
which is why we chose it to make it easier for folks like Dublin Core to
consider RDFa. Saving bytes is not that poor an excuse when you consider
the amount saved in a medium-sized dataset! Not repeating the same URL
over and over again is much cleaner, too.

> In any case, if we go in this direction there will also be people who
> don't bother to declare the profile, but that's OK; that just means that
> the relations in those documents won't be globally unambiguous, and
> anyone who makes assumptions about their meaning does so at their own risk.

Right, that's been our general approach at CC, given that RDFa is
specific enough that it's very unlikely someone made a valid RDFa
statement by mistake.

Note again that I'm not sure you can trigger everything in RDFa with
@profile. But the general idea of an HTML4 extension I agree with.

> AFAIK the alternative to this approach is to throw up our hands and
> admit that link relations in HTML4 are a lost cause, and anyone who uses
> them suffers from some semantic fuzziness.

Given the GRDDL example I gave above, I think we do need to consider
that @profile introduces a lot more semantic flexibility / fuzziness
than one might expect. I still think it's a viable model, but it is more
complicated for your use case, that's for sure.

-Ben

Received on Sunday, 1 March 2009 00:58:44 UTC