- From: Thomas Lörtsch <tl@rat.io>
- Date: Fri, 12 Jan 2024 19:35:36 +0100
- To: Olaf Hartig <olaf.hartig@liu.se>
- Cc: "lindstream@gmail.com" <lindstream@gmail.com>, "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
> On 12. Jan 2024, at 11:39, Olaf Hartig <olaf.hartig@liu.se> wrote: > On Thu, 2024-01-11 at 12:17 +0100, Niklas Lindström wrote: >> Can be encoded as: >> >> <t> rdfx:lexicalTriple "<urn:x:s> <urn:x:p> "l"^^<urn:x:d>" . > > I don't think that this idea of capturing the triple t of a named > triple (n,t) in the form of such a literal is going to work in general. > In particular, I foresee problems cases in which multiple named triples > have the same blank node in their respective triples. For instance, > consider two named triples (n1,t1) and (n2,t2) where t1=(s1,p1,o1) and > t2=(s2,p2,o2) such that, say, s1 and s2 are the same blank node. How > exactly would your literal-based representation of these two named > triples be defined such that it is possible for the N-Triples parser to > reconstruct the two named triples with the same blank node in their > subjects? Chiming in here, if you don’t mind, because NNG employs a similar approach to use graph literals to encode things that RDF 1.1 is not aware of. Blank node related issues can IMO be handled in different ways, foremost by: - skolemizing them - using graphs and making sure that all blank nodes of importance are captured with all triples in which they occur - a sort of Concise Bounded Description, although maybe restricted to those blank nodes that are deemed important - making sure that all blank nodes that encode elements of some meaning, i.e. that do not only encode structure, are skolemized, and accept that the rest might not co-denote after reconstruction. Either full skolemization or full CBDs seem to me like pretty straightforward options, the other approaches mentioned are admittedly rather handwaving attempts at optimization. > Yet, perhaps it is not even necessary to go there because, if we extend > the RDF data model with such a notion of named triples as possible > elements of an RDF graph, then I would expect the N-Triples format to > be extended accordingly. The purpose of the discussed mechanism is of course to ensure backwards compatability by encoding stuff that could trip up RDF 1.1 - e.g. by breaking monotonicity - without having to extend a format (at least if one doesn’t count a new datatype as an extension). Best, Thomas
Received on Friday, 12 January 2024 18:35:45 UTC