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

Ivan Herman wrote:
> A followup on the issue on generalized triples.
> 
>> On Wed, 2011-01-12 at 14:52 +0100, Ivan Herman wrote: 
>>> On Jan 12, 2011, at 14:46 , Dave Reynolds wrote:
>>>
>>>>> Heh. The discussion is raging exactly on those issues right now! Although I do have some reasons to back up generalized triples:
>>>>>
>>>>> http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0063.html
>>>> Sure. As you probably know Jena supports generalized triples internally
>>>> and indeed it is useful for reasoning. 
>>>>
>>>> However, *just* having generalized triples and not also an
>>>> RDF-conformant API is a pretty big step with implications for the RDF
>>>> WG! Certainly means it can't be a general purpose API given that some
>>>> existing backends can't support generalized triples.
>>>>
>>> To be honest, I am not sure I fully understand what you mean here. :-(
>> 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, 
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.

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

1: implementations which implement generalized triples but do not expose 
them to users

2: implementations which implement generalized triples and expose them 
to users via a second API

3: implementations which constrain their implementation of the Triple 
interface and don't support generalized triples

4: implementations and apis which support generalized triples, and 
serializations which don't

none of which seem particularly nice tbh

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

Received on Thursday, 13 January 2011 19:34:35 UTC