Re: Working Group Decision on ISSUE-120 rdfa-prefixes

On 04/07/2011 11:58 PM, Kurt Cagle wrote:
> A few quick comments here, as one who works with RDFa regularly for
> organizations such as the Library of Congress.
>
> 1) One of the principle reasons for prefixes in the first place is to
> differentiate between two distinct ontologies that may be coexistent in HTML
> content.

I thought that was the reason for *URIs*, not prefixes. Or, more 
precisely I thought that was the reason for making property names take 
the form (globally unique part, vocabulary local part). *Prefixes* seem 
to be intended as a solution to the problem "our choice of URIs for the 
globally unique part makes hand authoring difficult".

> 3) I would advocate that the HTML Working Group consider the possibility of
> establishing a white list of standardized RDF prefixes that will be
> interpreted properly by browsers even in the absence of binding URIs, and
> that some mechanism also be established that would provide a way to identify
> new prefixes for formal identification when the prefixes are not in this
> white list ( I know, proposing that mechanism would be preferable, and I
> hope to do so at some point soon).

I would be very interested to see this proposal. My non-fleshed-out 
proposal is basically:

* Prefixes get registered in a global registry. This is open to anyone 
and so places no limitation on the ability to invent new vocabularies.
* UAs that deal with specific vocabularies have a hardcoded list of 
things they support and can do simple string matching rather than 
complex prefix binding.
* UAs that want to do some form of follow-your-nose have to go via the 
registry to find the URI corresponding to a prefix.

I can also see that there are arguments in favour of retaining an 
un-prefixed raw-URI syntax that can be used for experimental 
vocabularies that are not expected to be widely deployed. This does 
introduce a slight complication in that clients might have to be updated 
to understand both the full-URI and prefixed form once the prefix is 
registered.

I believe all of this offers a worthwhile tradeoff of simplicity in the 
common case (authors writing a small number of known vocabularies, UAs 
process a small number of known vocabularies) at the expense of some 
extra complexity (an extra HTTP request for follow-your-nose, some 
possibility of breakage in clients that do simple string matching after 
a prefix is registered) for the uncommon cases.

> 4) I would contend that now, and for the foreseeable future, most RDFa will
> NOT in fact be generated by hand coding, but instead will be generated via
> some formal generative algorithm or user interface mechanism. The amount of
> hand coding of HTML will likely be far smaller (perhaps by several orders of
> magnitude) to the RDFa assertions introduced by document enrichment programs
> in particular. As such, any purported complexity of RDFa will mostly likely
> fall not upon the naive HTML coder but upon the developer of these
> algorithms, who likely will have a far higher incentive to get it right -
> Facebook not withstanding.

That sounds like an excellent reason to ditch the prefix biding 
mechanism entirely, irrespective of whether the property names are 
(fixed) prefix:name or raw URIs. For a machine it is no extra bother to 
write out some long URI lots of times, and not having a binding 
mechanism frees the programmer from lots of bookkeeping about which 
prefixes are in scope and so on. Needless to say it also makes writing 
client programs much easier.

Received on Friday, 8 April 2011 10:03:02 UTC