Re: Latest changes introducing the RDF API

Ivan Herman wrote:
> 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...

:) you know what's coming.. if OWL 2 in the OWL 2 RL specification, RIF, 
SPARQL, RDF API (and N3) all have more general notions of triples, then 
perhaps it's RDF which is inconsistent with it's own usage - again 
though, this is probably a really unproductive won't change topic.

For the RDF API, we've already discussed this previously where you 
yourself mentioned that often literals as subjects are needed for 
advanced usage, when querying and for rules etc, these modules wouldn't 
be able to use the API, or would have to break it compatibility wise, if 
we preclude literal subjects, so why go there just for the sake of 
consistency between specifications on an area that is already widely 
inconsistent and when the feature is actually required to process and 
use RDF in some cases?

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

I can live with that, in-fact if we could focus on these two levels and 
leave that "perfect" jquery like API for RDF completely out of this WG 
and up to library implementers [*], I'd be quite happy :)

* unless we get there between us as library implementers ourselves and 
find a nice usable common ground before the wg is done.

Best,

Nathan

Received on Monday, 18 April 2011 12:11:20 UTC