Re: Comments on ISSUE-108 (Link relations)

Hi,

My 2p worth: I think that RDFa should ignore all HTML link relationships.

RDFa's interpretation of these link relationships is a problem because it means documents are interpreted differently by processors that construct data about HTML documents (not about the data they contain, but about the HTML documents themselves) based on whether they do or don't understand RDFa.

For example, if you have a document at http://example.org/doc that looks like:

  <html>
    <head><title>Example Document</title></head>
    <body about="http://example.org/another-doc">
      <p><a rel="license" href="/license">License</a></p>
    </body>
  </html>

then according to HTML semantics, the document states:

  the license of http://example.org/doc is at http://example.org/license

On the other hand, an RDFa-aware processor will interpret it as saying

  the license of http://example.org/another-doc is at http://example.org/license

Note that this difference in interpretation also occurs when vocab is used:

  <html>
    <head><title>Example Document</title></head>
    <body vocab="http://purl.org/dc/terms/">
      <p><a rel="license" href="/license">License</a></p>
    </body>
  </html>

This is more subtle, as xhv:license and dct:license are probably more-or-less equivalent.

I think the safest thing to do would be to say that any of the list of link types in [1] are ignored, regardless of the context vocabulary. It means that if publishers want explicitly to use the HTML vocabulary or any predicate with one of those names, they must use a prefix or the full URI for the predicate.

An alternative would be to try to create triples for those link types based on the semantics in the HTML spec, but that's a bit hard for some of them (eg 'bookmark') as you can't guarantee that the appropriate subject for the triple is identifiable.

Cheers,

Jeni

[1] http://dev.w3.org/html5/spec/links.html#linkTypes
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Tuesday, 18 October 2011 22:23:26 UTC