Re: API question

Toby Inkster wrote:
> On Sun, 31 Oct 2010 16:25:08 +0000
> Nathan <nathan@webr3.org> wrote:
> 
>> Toby, see:
>>   http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0327.html
>>
>> Just raised this myself a few days ago - snap!
> 
> Great. I think this is a feature that's useful, but very problematic to
> implement it as specified. Some of the CURIE mapping stuff is similar.

Totally agree, to cover all use cases both our support for CURIEs and 
TypedLiteralConverters needs to be a basic k/v hash object (or expose 
the functionality of such a thing) something like the following:

interface X<T> {
   T get(String key);
   void set(String key, T value);
   void remove(String key);
   ? to(? in);
   ? from(? in);
}

So in the case of handling CURIEs T would be an IRI, the to method would 
convert from an IRI to a CURIE and a the from method would convert from 
a CURIE to an IRI.

And for TypedLiterals T would be a TypedLiteralConverter, the to method 
would accept a value like an int and return back a TypedLiteral, and the 
from method would accept a TypedLiteral and fire back a value of the 
appropriate type, like an int.

What the actual interfaces are, the method names, where they reside and 
indeed whether they are separate interfaces or whether a single 
interface exposes this functionality for both TypedLiteralConverters and 
CURIEs is a different matter, which probably needs addressed too.

> It could be redeemed quite easily though I think: just move all the
> DataContext functionality onto the DocumentData interface and get rid
> of DataContext/document.data.context/document.data.createContext. This
> should fix things, as all DataStore/DataQuery objects (i.e. the
> objects which actually use CURIE mapping and type conversion) are
> created using factory methods on DocumentData, thus could "remember"
> the DocumentData instance that created them, and use the type
> conversions and CURIE mappings defined there.

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).

The second point is that, names aside, I agree with the notion that we 
have two interfaces defined and perhaps only need one, in my previous 
mail [1] I quickly outlined the functionality it looks like we need:

[[
- Methods to create instances which implement the above interfaces
- Methods handle CURIEs
- Methods to handle converting to and from a typed literal
]]

Would appear to make sense to have them all together on a single interface.

As an aside, if they were all on the same interface, then it'd be 
possible to leverage them so that we could offer the following:

   x.createTriple(":me", "ex:age", 43);

Without adding any ambiguity in to the API, the only issue that would 
arise is how to handle data that isn't understood (a typed literal with 
no converter, a curie that isn't known), but this is an issue that 
exists anyway (as in what happens currently if somebody passes the above 
arguments in to createTriple).

Best,

Nathan

[1] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0356.html

Received on Sunday, 31 October 2010 21:47:19 UTC