[whatwg] Alternative method of declaring prefixes in RDFa

Just a couple of clarifications - not trying to convince anybody of
anything, just setting the record straight.

Henri Sivonen wrote:
> Even though switching over to 'prefix' in both HTML and XHTML would
> address the DOM Consistency concern, using them for RDF-like URI mapping
> would as opposed to XML names would remove the issue of having to pass
> around compound values and putting them on the same layer on the layer
> cake would remove most objections related to qnames-in-content, some
> usual problem with Namespaces in XML would remain:
>
>  * Brittleness under copy-paste due to prefixes potentially being
> declared far away from the use of the prefix in source.
>  * Various confusions about the prefix being significant.

There does not seem to be agreement or data to demonstrate just how
significant these "issues" are... to some they're minor, to others
major. I'm not saying it isn't an issue. It certainly is an issue, but
one that was identified as having little impact. RDFa, by design, does
not generate a triple unless it is fairly clear that the author intended
to create one. Therefore, if prefix mappings are not specified, no
triples are generated. In other words, no bad data is created as a
result of a careless cut/paste operation.

The author will notice the lack of triple generation when checking the
page using a triple debugging tool such as Fuzzbot (assuming that they
care).

>  * The problem of generating nice prefixes algorithmically without
> maintaining a massive table of a known RDF vocabularies.

This is a best-practices issue and one that is a fairly easy problem to
solve with a wiki. Here's an example of one solution to your issue:

http://rdfa.info/wiki/best-practice-standard-prefix-names

>  * Negative savings in syntax length when I given prefix is only used a
> couple of times in a file.

The cost of specifying the prefix for foaf, when foaf is only specified
once in a document, is:

len("xmlns:foaf='http://xmlns.com/foaf/0.1/'")
   + len("foaf:")
   - len("http://xmlns.com/foaf/0.1/") == 18 characters

The cost of specifying the prefix for foaf, when foaf is used two times
in a document is:

len("xmlns:foaf='http://xmlns.com/foaf/0.1/'")
   + len("foaf:")
   - len("http://xmlns.com/foaf/0.1/")*2 == -8 characters

So, in general, your setup cost is re-couped if you have more than 1
instance of the prefix in a document... which was one of the stronger
reasons for providing a mechanism for specifying prefixes in RDFa.

>> The reason that we used xmlns: was because our charter was to
>> specifically create a mechanism for RDF in XHTML markup. The XML folks
>> would have berated us if we created a new namespace declaration
>> mechanism without using an attribute that already existed for exactly
>> that purpose.
> 
> The easy way to avoid accusations of inventing another declaration
> mechanism is not to have a declaration mechanism.
> 
> URIs already have namespacing built into their structure. You seem to be
> taking as a given that there needs to be an indirection mechanism for
> declaring common URI prefixes. As far as I can tell, an indirection
> mechanism isn't a hard requirement flowing from the RDF data model.

We did not take the @prefix requirement as a given, it was a requirement
flowing from the web authoring community (the ones that still code HTML
and HTML templates by hand), the use cases, as well as the RDF
community. I would expect the HTML5 LC or CR comments to reflect the
same requirements if WHATWG were to adopt RDFa without support for CURIEs.

> After all, N-Triples don't have such a mechanism.

You are correct - N-Triples do not... however, Turtle, Notation 3, and
RDF/XML do specify a prefixing mechanism. Each do so because it was
deemed useful by the people and workgroups that created each one of
those specifications.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Website Launch
http://blog.digitalbazaar.com/2009/01/16/bitmunk-3-1-website-launch

Received on Monday, 19 January 2009 18:27:52 UTC