- From: Nathan <nathan@webr3.org>
- Date: Thu, 13 Jan 2011 19:32:24 +0000
- To: Ivan Herman <ivan@w3.org>
- CC: Toby Inkster <tai@g5n.co.uk>, W3C RDFa WG <public-rdfa-wg@w3.org>
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