Re: HTML WG: ISSUE-120 Use of prefixes is too complicated for a Web technology

Below are some notes regarding the deployment of RDFa out there on the Web
from the perspective of a developer who is NOT part of the RDFa WG.

A few weeks ago, Dries Buytaert announced that Drupal Gardens had reached
20,000 websites [1]. All these sites run Drupal 7 which has RDFa support by
default, that means 20,000+ sites relying on the RDFa prefix mechanism on
all their pages. Considering that the Drupal open source software is still
in beta at this point, you can expect this number to sky rocket in the next
few months. Breaking backwards-compatibility would make it a very bad idea
to deprecate CURIEs and prefix mechanisms from RDFa. Drupal Gardens is just
one example among many others like the White House, Best Buy, etc. The RDFa
train has already left the station, the prefix mechanism is already part of
too many websites and softwares to be considered for deprecation.

By using several namespaces, we were able to describe different kind of
information such as taxonomies (SKOS), online content (SIOC) and their
authors (FOAF) all in the same pages. Without the use of prefixes and these
respective namespaces, this would have been much more complicated and
convoluted. CURIEs make this mix and match much easier and less error prone
than having to deal with long URIs. As to the argument regarding complexity,
since we started talking about the RDFa CURIE/prefix pattern in 2008 [2] and
after presenting it at several Drupal conferences, no one has ever
complained about it. Ultimately, and to reiterate Toby's argument,
developers will want to use prefixes regardless in order to abbreviate URIs,
so this is a very important aspect of the spec (and one that makes
explaining and implementing RDFa easier too).

regards,
Steph.

[1] http://buytaert.net/20000-drupal-gardens-sites
[2] http://groups.drupal.org/node/16597


On Wed, Sep 22, 2010 at 11:12 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> Ian,
>
> I've tried to represent your opinion on HTML+RDFa and CURIEs in this
> e-mail. Please correct anything in here that does not accurately
> represent your position re: CURIEs/prefixes/etc in HTML+RDFa.
>
> On 09/16/2010 06:47 AM, Nathan wrote:
> > Is the HTML editor open to having first class support for
> > prefixes/CURIEs in HTML, such as the introduction of a new metadata
> > element "prefix" with the attributes @name and @href (or "curie" with
> > the attributes @prefix and @href)?
>
> I do not believe that Ian is open to that particular mechanism. Ian is
> asserting that the use of prefix:reference mapping (aka: CURIEs) in
> HTML+RDFa is too complicated for most authors and that they will get it
> wrong.
>
> We have attempted to mitigate Ian's various concerns by introducing
> three new concepts in RDFa 1.1 - allowing full URIs everywhere, RDFa
> Profiles and the @prefix attribute. He is fine with allowing full URIs
> everywhere. I'm pretty sure that he does not like the @prefix solution
> as a replacement for @xmlns and would claim that the "solution" misses
> the point. I'm also pretty sure that he is against having an indirection
> mechanism where strings map to other strings declared earlier in the
> document (the whole concept of CURIEs).
>
> > i.e. is the HTML editor looking to introduce well defined and easily
> > maintainable prefix/curie support in to HTML?
>
> No, he is not.
>
> > or conversely, is the HTML
> > editor looking to relegate @prefix on the grounds that it's too
> > complicated and difficult to maintain moving forwards, without proposing
> > or seconding an alternative solution?
>
> Ian is suggesting that any CURIE-like mechanism should be removed from
> the HTML+RDFa specification. The alternative solution, as I understand
> it, is to use full URIs everywhere, or pre-define tokens that should be
> used when describing particular semantic objects... basically, what
> Microdata does. He has also stated that he is open to other mechanisms
> that accomplish our goals that have yet to be discovered.
>
> > as an aside, if @prefix is defined by a specification which extends
> > HTML, then does it fall under the HTML editors remit to maintain @prefix?
>
> Strictly speaking, no it does not. Ian will most likely treat @prefix in
> the same way that he has treated the HTML+RDFa spec, as something built
> on top of HTML5.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Saving Journalism - The PaySwarm Developer API
> http://digitalbazaar.com/2010/09/12/payswarm-api/
>
>