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

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


> 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

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

> 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