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

On Jan 16, 2011, at 18:26 , Andy Seaborne wrote:

> (no comments list - I'm guessing I just email here)

You did the right thing!

[snip]
>>> 
>>> AFAICT that leaves us with four choices:
> 
> Good list.
> 

[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