W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2011

Re: Latest changes introducing the RDF API

From: Ivan Herman <ivan@w3.org>
Date: Mon, 18 Apr 2011 13:56:36 +0200
Cc: benjamin.adrian@dfki.de, Manu Sporny <msporny@digitalbazaar.com>, RDFa WG <public-rdfa-wg@w3.org>
Message-Id: <3E71E0A4-EC53-40BC-A09B-B8656614B35C@w3.org>
To: nathan@webr3.org

On Apr 18, 2011, at 13:49 , Nathan wrote:

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

:-)

My point is: W3C recommendations should have a consistency among themselves. The RDF API is closely related to RDF; if that latter does not allow literals as subjects, then it would look quite strange if the RDF API Rec allowed it...

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

Good question. And I believe the answer is yes. My concern here is that JS programmers should be able to make use of RDF data that is already on the Web and I do not mind if, on that level, this is based on a read only thing.

Yes, for many of the issues you raise, one will have to go down to the RDF API level. And that is fine. So we should not solve them on that 'middle' layer. But a simple API for simple tasks should be available...

Ivan






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


----
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:56:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:51 UTC