RDFa API more feedback

Hi All,

aside: Will take all of this feedback and merge it in to a single 
document/mail with all IDL etc in the near future.

I've finished up a first implementation of the RDFa API using the 
interfaces as per my last big mail, so far only implemented an NT parser 
though!, good news is it's pretty good for a lot of things, certainly 
read related.. not so on the creation side. Moving on to specifics..

0: working with triples as a sequence rather than an index (s[p][o]) is 
really, really, difficult for many things - imho one should/must be able 
to get a hash of property->object for each subject easily from a 
DataStore - I'm going to try a few different methods out tonight and 
will send feedback / some alternatives.

1: IRIs are a complete PITA to work with, like really, for example here 
is the real code for (if property is foaf:knows) ->
triple.property.toString() == 
data.context.resolveCurie('foaf:knows').toString()
on the one hand they need to be strings, and on the other we need curie 
resolution etc in there - I know IRI could extend String in js without a 
problem and this would be v nice to work with, but needs some thought on 
how best to approach from an RDFa API perspective.

2: the create*** methods really need to be on the DataContext interface, 
it's a complete pita to work with when they're on DataStore or DocumentData.

3: we could do with specifying that implementations must implement 
TypedLiteralConverters for all xsd numerical types 
(xsd:int/double/decimal/unsigned* positive* etc.)

4: convertType has the type as optional? think this may be a bug as it's 
required (unless I'm really missing something?)

5: DataStore could do with a toArray() method returning 
sequence<RDFTriple> - it really helps and is a good practical addition.

6: DataParser is dependent on having access to both the create*** 
methods and the convertType functionality, thus it needs to either have 
a constructor which accepts DataContext (dependency injection) if the 
create methods are moved here, else accepting DocumentData - if not here 
then as a required argument on DataParser.parse and process.

7: CURIE resolution, specifically casing of the prefix needs defined, 
very much appears it should be case insensitive, as in XSD:boolean == 
xsd:boolean and both resolve.

8: relative URI resolution, and 'base', it seems like DataContext needs 
to have a 'base' which it's working off, and that can be modified with a 
setBase method, this is needed (currently) for CURIE resolution, and for 
relative uri resolution. Also DataParser needs to be aware of a base for 
many serializations and where the base is not set in the document.

9: the form of name for registerParser() and getParser() needs to be 
decided and specified soon. Also it's a weird area, because with many 
parsers you have one per media-type, however in HTML land you need 
different ones for different profiles - I'm unsure what the best 
approach is, but would say that we definitely need to tell people what 
to pass in to get the parser they want back!

10: it would be nice for users to be able to get back a list of existing 
prefix maps in the data context, this would be handy for some 
serializers as well.

11: we *need* to ensure that TypedLiterals are created even when we 
don't have a converter for the type - after working with the API it 
makes no sense at all to have "13"^^xsd:short fail to create a 
triple/typedliteral because there's no converter - rather we need a way 
to test if a TypedLiteral has a native value or not.

12: creating RDF really isn't nice with this API, it works perfectly, 
but it's so verbose it's certainly off-putting - for instance here's the 
code to create these two triples { :me foaf:name "Nathan"@en; 
cert:decimal 65537 } ->

  data.context.setMapping( "" , "http://webr3.org/nathan#" );
  data.context.setMapping( "cert" , "http://www.w3.org/ns/auth/cert#" );

  var iri = data.createIRI(":me");
  var blanknode = data.createBlankNode();
  var plainliteral = data.createPlainLiteral("Nathan", "en" );
  var typedliteral = data.createTypedLiteral("65537", "^^xsd:int" );
  var t1 = data.createTriple(iri, data.context.resolveCurie('foaf:name') 
, plainliteral );
  var t2 = data.createTriple(blanknode, 
data.context.resolveCurie('cert:decimal') , typedliteral );

13: Need to define what the `value` + toString() of TypedLiteral and 
PlainLiteral should be, especially PlainLiteral. As in should it have \t 
or a tab, likewise for \r \n and for special chars, unicode etc.

14: RDFTriple.toString returns NTriples, which means there is a 
dependency on a *full* NTriples serializer in the API - makes sense but 
I'd strongly suggest we provide this functionality with full toNT 
methods on all RDF Interfaces, any implementation of the API already has 
this dependency, we're just not exposing it atm.

Think that's almost everything,

Best,

Nathan

Received on Thursday, 30 September 2010 13:06:54 UTC