Re: Latest changes introducing the RDF API

Ivan Herman wrote:
> On Apr 18, 2011, at 12:18 , Nathan wrote:
>> Ivan Herman wrote:
>>> This is not a detailed review of the API document, just reaction based on a cursory look.
>>> - I am opposed to include a Graph Literal interface. Unless the RDF WG decides to allow graph literals, we should not introduce something in the RDF API that clearly goes beyond RDF. Extensions may do it, the core RDF API should not...
>> Does this also apply to the other features that go beyond RDF, such as support for blank node predicates and literal subjects?
> 
> I know you will hate me for this, but my answer is yes...

I'd certainly never hate you Ivan! But as you know I'd disagree, 
although that's a topic fro another day or thread methinks.

>> [snip]
>>> What the RDFa API found as a beautiful balance and provide a high level interface for those who do not really care about RDF, is missing here.
>> I agree it's missing, as above, but unsure whether it should even be an API, or is beneficial doing, to me it seems better results would come from getting core functionality out there and available for RDF heads and advanced developers, then they'll create some awesome libraries for end users on top of it.
> 
> But... We already have, in RDFa API:
> 
> getSubjects, getProperties, getValues,
> getProjection, getProjections,
> the Projection interface
> setMapping
> 
> None of these are RDFa specific, in fact, except for the fact that in the RDFa document they are part of the document.data. This collection of interfaces and methods form, in fact, a high level API to RDF data parsed from some source.

I agree, none of them are RDFa specific, and they certainly look to 
cover some of the main functionality (haven't actually used them in real 
code yet though or seen implemented of course) - my key question though, is:

   are we talking about providing a read only API?

Things get several shades more complex when we turn this in to a read 
write API and consider things like collections vs multiple values, 
datatypes, languages, forward and backward links and so forth...

> What I am proposing is to have a layer on top of the RDF API, possibly in a separate document, that contains only those interfaces. What I would hope for is that many of the Javascript programmers will be happy with that layer. Of course, just as in the RDFa API, there would be a 'hook' to get to the low level RDF API, but that is only for geeks...

Layer above sounds fine of course, I just worry that the simple methods 
of the read only RDFa API wouldn't quite cut it for general RDF/linked 
data usage, as outlined above.

Best,

Nathan

>>> More specifically, we should have somewhere (in another document, perhaps) the projection interface and the necessary functions around it as a separate layer that could be on top of the RDF API but is not bound to RDFa. It should be possible to use such an interface while the data is parsed from a turtle file on the Web.
>> I certainly wouldn't mind spending some time working on resource/subject/object oriented APIs here, like the Projections - I'm sure a few of us have already had a stab at this in our own libraries (my own last attempt was js3) - again though, I strongly feel that we'd need to back it up with code and standardize between at least 3 working libraries with slightly different approaches (existing or to be created soon), and do it as a different document, focussed at end non-rdf developers rather than RDF heads.
>>
>>> I do believe we have all this, it is a matter of editing and make it more explicit...
>> Hmm, I believe we can see it there somewhere, but don't have it yet, could probably get there though with some good coding, experimenting, and real world daily use of that code.
>>
>> Best,
>>
>> Nathan
>>
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
> 

Received on Monday, 18 April 2011 11:50:11 UTC