Re: Representing Named Triples as Just Triples

On Fri, 2024-01-12 at 19:35 +0100, Thomas Lörtsch wrote:
> 
> > 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:

All these bullet points below are just mentioning general ideas. I have
asked for a concrete definition. The devil is in the details.

I have quickly looked at the 'graphLiterals.md' document in you NNG
repo [1] but I didn't find anything concrete there either. If you want
to introduce a datatype (such as the one denote by the IRI nng:ttl in
your document), you have to define its lexical space, its value space,
and a corresponding lexical-to-value mapping [2].

Best,
Olaf

[1] https://github.com/rat10/nng/blob/main/graphLiterals.md

[2] https://www.w3.org/TR/rdf11-concepts/#dfn-datatype


> - 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 21:06:25 UTC