Re: Representing Named Triples as Just Triples

> 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