W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > November 2010

Re: API question

From: Nathan <nathan@webr3.org>
Date: Mon, 01 Nov 2010 11:17:04 +0000
Message-ID: <4CCEA1B0.20408@webr3.org>
To: Toby Inkster <tai@g5n.co.uk>
CC: public-rdfa-wg@w3.org, Manu Sporny <msporny@digitalbazaar.com>
Toby Inkster wrote:
> On Sun, 31 Oct 2010 21:46:37 +0000
> Nathan <nathan@webr3.org> wrote:
>> Two points here, one is why should any object need to remember the 
>> DocumentData instance that created them? currently the only one that 
>> needs anything like this memory is TypedLiteralConverter and that's
>> only because it has a toValue() method, it would be very easy and
>> clean to simply drop that toValue method and ensure that DocumentData
>> or DataContext (or something!) had a fromTypedLiteral(in TypedLiteral
>> t) method on it (and the converse, as outlined above).
> Stores don't need a route back to the TypedLiteralConverter registry,
> but they do need a route back to the CURIE prefix registry thanks to
> createTypedLiteral, createTriple, etc.

do see ISSUE-51 [1]

by moving the create*** methods on to the same interface as setMapping 
and resolveCurie then we can easily expose the following functionality

   context.createTriple(":me", "rdf:type", "foaf:Person");

and if we take the steps outlined in my previous mail [2] addressing 
ISSUE-57 then we can also enable

   context.createTriple(":me", "ex:age", 37 );
   context.createTypedLiteral( new Date() );

and if we add in a simple rule saying that strings which aren't curies 
map to PlainLiterals then we can also enable:

   context.createTriple(":me", "foaf:name", "nathan" );

> CURIEs are allowed all over the API, but unless the objects that make
> use of them have a route back to the prefix mapping list, I can't see
> how they're going to work. I'm starting to think that using closures
> for prefix mapping will solve a lot of problems.
> a la:
> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0131.html
> The way we're doing it now seems awfully complicated for something that
> could easily be implemented in "user space".

TBH, after implementing the API (with most of the changes listed in 
issues 49-59) I didn't find this a problem either implementation wise or 
as a user, primarily due to moving the create** methods on to 
DataContext, and the changes above would be the icing on the cake so to 

There are were still a couple times I found it beneficial to use 
closures, but that was mainly for optimization reasons (save having to 
resolve a CURIE each time), especially in static functions which were 
called often.

However overall it was nicer to use the familiar CURIE syntax, and it'd 
be even nicer if (as outlined above) one could use "foaf:name" rather 
than context.resolveCurie("foaf:name") or even foaf = ns('http://...); 

ps: for the record the var c = context.resolveCurie; c("foaf:name"); 
approach doesn't work because resolveCurie isn't a static function thus 
`this` can't be resolved internally.

[1] http://www.w3.org/2010/02/rdfa/track/issues/51
[2] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Nov/0000.html


Received on Monday, 1 November 2010 11:17:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:22 UTC