Re: Representing Named Triples as Just Triples

> On 12. Jan 2024, at 22:06, Olaf Hartig <olaf.hartig@liu.se> wrote:
> 
> 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.

Blank nodes are notoriously difficult. They pose problems that are impossible to solve algorithmically, see for example Section 4.1 Shared blank nodes, unions and merges in the RDF 1.1 Semantics [3]. Saying that a reference to either skolemization or CBD is just bullet points doesn’t the justice to my answer as there is no better answer.

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

Sure, and thanks for taking a look, but a) that’s nothing to do with the blank node problem and b) I still have to fix some more fundamental problems in NNG and I have to keep up with this WG which faces even more fundamental problems. But on a yet more fundamental note: I was an architect in a former life, a real one for houses and such. At university we also learned to do statics and back then I could calculate a small house or a simple bridge. In essence however we learned how to know that we are on the safe side with our design and the exact calculations of how much steel to put into the concrete are done by specialists that only do statics. What architects really do is analyze and understand demand and means, and make those ends meet, ideally in a pleasant looking way. There are buildings who very much depend on the statics done right: the CCTV building in Bejing that I personally admire very much would not have been possible without a genius structural engineer like Ove Arup. The smeantics of Named Graphs, that intricate construction combining name and graph took a semanticist like Pat Hayes to come up with. Defining the lexical space, value space and corresponding lexical-to-value mapping of graph literals is hardly a problem of such stature.

That’s how I approach NNG: I need to know that I’m on the safe side with respect to certain formal aspects like said lexical-to-value mapping. When I’m done with the conecptual problems and the model-theoretic formalization of nesting graphs and such and have written everything down in a concise and readable paper and still no gracious soul has turned up and presented me said mapping, then I will eventually do it myself. It will probably take me a day or two to figure out how to do it and be sure that I did it right. It will take some semanticist probably not even an hour. And if it turns out to be so complicated that it takes them longer, then I don’t see why I should even bother to start on doing it. And if it turns out to be impossible, well, then there you go backwards compatibility, and lets just define a new term type - as you suggest. IMO the important thing right now, and my job, is to ensure that the basic design is done right and that I’m on the safe side with everything. So far I’m pretty confident that I am.

Best,
Thomas


> Best,
> Olaf
> 
> [1] https://github.com/rat10/nng/blob/main/graphLiterals.md
> [2] https://www.w3.org/TR/rdf11-concepts/#dfn-datatype

[3] https://www.w3.org/TR/rdf11-mt/#shared-blank-nodes-unions-and-merges


>> - 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 23:38:56 UTC