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

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

On 14/01/11 10:52, Ivan Herman wrote:
>
> On Jan 13, 2011, at 20:32 , Nathan wrote:
>
>>>>> On Jan 12, 2011, at 14:46 , Dave Reynolds wrote:
>>>> If you only provide a generalized triples API then you encourage people
>>>> to create or assume graphs that can't currently be serialized and
>>>> shared. Bad thing. Especially since changing that is currently
>>>> explicitly "out of scope" for the RDF working group.
>>
>> I have to agree that the serialization constraints are a bit of a worry,
>
> Yes, this is a good point
>
>> it's a shame that a simple generalized to constrained triples mapping can't be done with a tightly defined rdf:value type property, such that a triple like:
>>
>>   "foo" x:bar "baz" .
>>
>> could be serialized as:
>>
>>   _:s1 x:bar "baz" ; rdf:nodevalue "foo" .
>>
>> but I guess that's a different issue.
>
> Indeed:-)
>
>>
>>>> If you only provide an API matching the RDF syntactic constraints you
>>>> limit future options if the spec eventually changes and you make writing
>>>> things like inference engines using the API harder.
>>>>
>>>> Jena's solution is to have the internal "SPI" provide generalized
>>>> triples but have the normal convenience API enforce the RDF constraints.
>>>>
>>>> That way normal users produce data which they can serialize but backend
>>>> providers and inference engine developers can work without constraints.
>>
>> AFAICT that leaves us with four choices:

Good list.

>>
>> 1: implementations which implement generalized triples but do not expose them to users
>
> What would that exactly mean? I am not sure I understand. Can I create generalized triples and add them to the triple store, even if through some low level methods? Or does it mean that the API spec remains silent on the constraints and implementations are free to do what they wish?
>
>>
>> 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.

>> 3: implementations which constrain their implementation of the Triple interface and don't support generalized triples
>>
>
> This seems to lead to possible problems for some applications, see my reasoning examples

I confess I don't see how this variation helps.  It creates friction to 
the exchange of information when some systems generate triples others 
can't process and the application code isn't portable across 
implementations of the API.

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

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

Received on Sunday, 16 January 2011 17:26:49 UTC