Re: Generalized triples (Fwd: Non-Javascript RDF API-s?)

Hi All,

The RDF API defines a set of standardized interfaces for working with 
RDF data in a programming environment.

These interfaces are, and have to be, designed to enable:
  - interoperability between library and extension developers
  - modularity (separate interchangeable components)
  - standardized interfaces giving access to core functionality

If we are to be successful in the definition of this API, then we need 
to ensure the nice jQuery-for-rdf-like library works with foo-reasoner, 
bar-store and baz-query, that users can mix and match components to get 
their ideal setup; that innovation in libraries and specialization in 
components is encouraged, rather than stifled.

So, the question is, do the components require GTs in order to be 
interoperable or not?

In order to answer this question yourself, all you need to do is look at 
the Triple interface defined in your preferred library, and see if it's 
defined as (node s, node p, node o).

Personally, I already know the answer is yes, and all I'm hearing is 
other library developers and users agreeing, specifically pointing to 
good reasons why and where they are needed, and then finally concluding 
that there's a problem because the triples they need to create and use 
can't be serialized, aren't defined by the RDF core model, and thus all 
mention of GTs must be hidden from the general user (or words to that 
effect).

With regards the "split API" approach, regardless of what it would be 
called or how it would be described, the end result would still be the 
GT interface in the specification and implemented by libraries.

Best,

Nathan

Ivan Herman wrote:
> On Jan 16, 2011, at 18:26 , Andy Seaborne wrote:
> [snip]
>>>> 2: implementations which implement generalized triples and expose them to users via a second API
>>>>
>>> That seems to be the Jena approach. I am not sure I like it...
>> Jena splits the API goals into two parts - an upwards facing one for application, and a downwards facing one to storage (storage is not just persistence - in fact it includes inference as well - bad name - the term SPI is used for this API where S = System.)
>>
>> The application API does not allow un-serializable triples to be created.  This means that data created by an application is interchangeable with other systems.
>>
>> At the storage level, (and inference and SPARQL), some generalization of triples is helpful for implementation reasons, and being able to use the machinary/interfaces of triple storage.  They should not escape to the RDF-only API.
>>
>> This split into storage and application facing APIs might be useful to the RDF-API work.  It would suggest that storage provide add/delete/find where "find" is a simplified filter that only has each of the 3 slots in a triples as fixed or wildcard.  Storge can be generalized triples (all possibilities?).  The graph interface then presents the richer functionality to applications.
>>
> 
> I am not sure how that would be translated to our API, I guess Nathan could/should tell us... But I am concerned about the complexity. The user base of this API is probably much more critical then the average Jena usage base. The former is a bit skeptical about RDF and its complexity...
> 
> [snip
>>>> 4: implementations and apis which support generalized triples, and serializations which don't
>>>>
>>> Obviously, serializations should not support GT-s, they should silently ignore them.
>> That isn't obvious to me.  Wouldn't it be better to indicate to the application that the data can't be serialized as RDF at the point of serialization, so it isn't discovered by having to debug across systems to find the missing data.
>>
> 
> Right. Some error/warning mechanism is indeed good to have.
> 
> Ivan
> 
> 
> 
>> 	Andy
>>
>>>> none of which seem particularly nice tbh
>>> I agree, and I am not clear either which one to choose...
>>>
>>> I.
>>>
>>>
>>>>>> All a matter of goals for the API.
>>>> Personally I favour future compatibility and functionality, but at the same time half the point of standardization is limit unexpected functionality - so, I'm at odds with my own opinion on this tbh.
>>>>
>>>> caveat: obviously I favour getting a new media type asap which does fully support generalized triples, something between turtle and n3 and similar to amord in RDF - or, some form of backwards compatible mapping as mentioned earlier. (ultimately favouring a long term solution)
>>>>
>>>> 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, 17 January 2011 10:13:55 UTC