Re: ISSUE-76: If we fixed namespaces, does RDFa still have problems?

On Tue, 2009-12-15 at 17:20 +0200, Henri Sivonen wrote:
> On Dec 14, 2009, at 03:29, Manu Sporny wrote:
> 
> > Microdata:
> > 
> > <div itemscope>
> > <p>My name is <span itemprop="name">Aryeh Gregor</span>.</p>
> > </div>
> > 
> > RDFa:
> > 
> > <div about="#me" vocab="myvocab.html">
> > <p>My name is <span property="name">Aryeh Gregor</span>.</p>
> > </div>
> > 
> > or
> > 
> > <div about="#me" xmlns:myvoc="http://ficticious.url/vocab#">
> > <p>My name is <span property="myvoc:name">Aryeh Gregor</span>.</p>
> > </div>
> 
> Are these RDFa examples complete without an id="me" somewhere? That
> is, is baseuri#me supposed to be an imaginary URL that doesn't
> dereference to a node but is just talked about or is it supposed to
> point to a node?

This is a question that's important, but orthogonal to RDFa (it applies
equally to, say, Microdata's itemid attribute). 

I'm personally of the opinion that a URI should identify precisely one
thing, so for the given examples, in an ideal world, there would *not*
be an id="me" attribute anywhere in the document. If there were such an
attribute, it would introduce confusion as to what the URI <baseuri#me>
represents - does it represent a section of a document, or does it
represent a person called Aryeh Gregor?

There are of course valid situations when you'd want to provide paired
id and about attributes. One example is when you're providing metadata
about a specific element or part of the document:

 <section id="foo" xmlns:dc="http://purl.org/dc/terms/">
   <p>...blah...</p>
   <div about="#foo" property="dc:modified"
        content="2009-12-15">Last changed today.</div>
 </section>

>  * Generating more than one triple per element is confusing.

It can be, but in my experience writing RDFa, I think it's better than
the alternative of forcing authors to create additional elements to
carry extra data.

I often find myself wishing I could squeeze extra triples into existing
elements.

>  * Conflict with existing rel token processing (due to not requiring
> Safe-CURIE there).

In practise, I can't remember having seen this cause an issue in the
wild.

>  * Namespaces are a complication for implementors.

Not sure if you're referring to consumers or producers. Or perhaps both?

There are certainly several annoyances when parsing RDFa. Namespaces are
one of them. But most of the annoyances come from the underlying host
language - processing language attributes is annoying (mostly because
you have to make sure to ignore invalid attributes); resolving relative
URIs is something I could do without; XML canonicalisation is also quite
irritating.

As an RDFa author though, many of the hoops that RDFa processors have to
jump through are the little tricks that save me time. I don't want to
have to spell out all URIs in full, so CURIEs and relative URIs provide
me with a good shortcut. I certainly don't want to specify an xml:lang
attribute on every single element, so I'm happy I can just add one to
the root element and rely on that being inherited by all its
descendants.

As an author of RDFa documents, the one things that does get on my
nerves is that the use of CURIEs isn't optional. When handwriting RDFa,
splitting URIs into prefix and suffix isn't a problem, but when machine
generating it, it's an annoyance. Depending on how you're generating
your RDFa, it might not be a problem - if you're writing, say, a CMS
which uses a fixed set of property and class URIs, it won't cause any
pain. But if you're trying to serialise arbitrary RDF data to RDFa, it's
an extra step that you'd rather not go through. I'm pleased that
allowing full URIs in currently CURIE-only attributes is planned for the
next version of RDFa.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Tuesday, 15 December 2009 17:16:39 UTC