W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > January 2011

Re: PROPOSAL to close ISSUE-61: Does the RDFa API need a vocabulary helper

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 12 Jan 2011 23:27:12 -0500
Message-ID: <4D2E7F20.7030006@digitalbazaar.com>
To: Ivan Herman <ivan@w3.org>
CC: RDFa WG <public-rdfa-wg@w3.org>, Tim Berners-Lee <timbl@w3.org>
On 01/03/2011 12:42 AM, Ivan Herman wrote:
>> For example, the following is possible when using the RDF API:
>> 
>> var rdf = document.data.rdf; rdf.prefixes.foaf =
>> "http://xmlns.com/foaf/0.1/"; var foafname =
>> rdf.resolve("foaf:name"); // at this point, foafname ==
>> "http://xmlns.com/foaf/0.1/name"
>> 
>> Given the code above, the following is also possible using the RDF
>> API:
>> 
>> var short = rdf.prefixes.shrink(foafname); // at this point short
>> == "foaf:name"
> 
> The direct counterpart of the original issue/proposal would be to
> have a definition of prefixes so that I could also say
> 
> var foafname = rdf.prefixes.foaf('name')
> 
> Ie, once I have defined the prefix I would not have to repeat it
> verbatim because it becomes a function of its own right.

Hmm, this is an interesting twist on what's in the spec right now and
may address your request below, Ivan.

I haven't tried this out, so there may be something preventing us from
doing this in JavaScript, but basically, we'd change the PrefixMap
interface from this:

omittable getter DOMString get(in DOMString prefix);
omittable setter void set(in DOMString prefix, in DOMString iri);

to this (note the change in return type for get()):

omittable getter PrefixResolver get(in DOMString prefix);
omittable setter void set(in DOMString prefix, in DOMString iri);

[Callback]
interface PrefixResolver
{
   DOMString resolve(in DOMString prefix);
}

Internally, the setter for the PrefixMap would create a new function
object and set an attribute named to the value of the 'prefix' argument
passed into the set() method in the PrefixMap. For example:

rdf.prefixes.foaf = "http://xmlns.com/foaf/0.1/";
var foafname = rdf.prefixes.foaf("name");

foafname would be "http://xmlns.com/foaf/0.1/name" at this point.

or one could even do:

rdf.prefixes.foaf = "http://xmlns.com/foaf/0.1/";
var foaf = rdf.prefixes.foaf;
var foafname = foaf("name");

foafname would be "http://xmlns.com/foaf/0.1/name" at this point.

This would allow you to change foaf to be something else, but enclose
the current 'foaf' PrefixResolver function in a closure and keep it for
as long as one needs it.

> I must admit I am not convinced about the 'confusion' argument. I
> understand that, mainly for RDFa developers having only a method that
> always uses the full CURIE (ie, 'foaf:name') is more understandable.
> But, for RDF developers, I would find a coding pattern of the form
> foaf('name') much more intuitive.

I'd rather have something that is consistent across both the RDF API and
RDFa API. If someone is using "foaf:name" in the RDFa API, it'll be
jarring to not have that mechanism available to them in the RDF API. The
same goes for foaf("name") - if that's what they use in the RDF API, why
do they have to use "foaf:name" in the RDFa API? Shouldn't the mechanism
be the same across both APIs? That's partly what I mean by "confusion".

That said, it may not harm us to provide both mechanisms (as outlined
above via the PrefixResolver interface) and let the developer decide
which one they'd like to use. This may require us to support something
like this in the RDFa API:

var foaf = document.data.createResolver("foaf",
                                        "http://xmlns.com/foaf/0.1/");
var foafname = foaf("name");

Assuming that the PrefixResolver approach is technically possible, would
only modifying the RDF API address your concern Ivan? Or would you want
there to be this foaf("name") mechanism in both the RDFa API and RDF API?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Linked Data in JSON
http://digitalbazaar.com/2010/10/30/json-ld/
Received on Thursday, 13 January 2011 04:27:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:08 GMT