General feedback on the RDFa API draft

Hi All,

precursor: much of what follows may be addressed by changing the title 
to 'RDFa DOM API' and stating 'An API for extracting structured data 
from Web documents in a User Agent that implements the DOM' :)

Without delving in to too many specifics, I'm slightly (something) that 
the RDFa API only caters for handling RDFa inside a User Agent with DOM 
support, it appears to me that the API could easily be split so that 
core functionality could be implemented in any context.

side: To quickly touch on subject.origin (or subjectOrigin), given that 
one may pull in several resources via XHR and add them to a single 
DataStore, how would this affect the subject.origin, and moreover what 
about the origin of the triple (as in the URI/Document/NG it came from) 
- what we typically think of as the ?g in a quad.

Back to the specific issue of 'only works if you have a DOM', here's a 
specific scenario:

The rdflib.js from tabulator currently supports RDF/XML, N3 etc.. RDFa 
support is currently being added - this could easily be an 
implementation of the RDFa API - however the code also currently works 
on the server side (in V8, node.js and suchlike), so it's a kind of 
universal library, but if we upgraded it to use the RDFa API, then 
server side support would be lost.

If however the RDFa API was created with this consideration in mind, 
then it could be implemented in not only rdflib.js, but any server or 
client side rdf library. Moreover, it would set the way to align 
everything but serialization specific parsing with RDFa API, essentially 
creating a one for all RDF API - I'm sure you can see the benefits in 
this, failing that even a one for all RDFa API that can be implemented 
outside of the current generation of User Agents would be nice.

Apologies for introducing multiple issues for you to consider, perhaps 
not everything is in scope, and I'm unsure if it needs addressed but 
just some thoughts.


Best,

Nathan

Received on Friday, 18 June 2010 23:37:54 UTC