Re: Representing Named Triples as Just Triples

Hi Niklas,

I obviously was hoping that your answer to my question yesterday would
be different ;-)  Anyways, I am responding inline below in the second
of the two emails about your latest proposal and then switch to a quote
from the first of the two emails. I will mainly ask questions to better
understand the basic elements of your proposal.

On Thu, 2024-01-11 at 12:17 +0100, Niklas Lindström wrote:
> Further update; TL/DR: Named triples do *not* (AFAICS) have to name
> one specific triple. It only "makes sense" to name multiple triples
> with the same claim identifier if they are of the same reason. See
> below for how that is so.
> [...]
> 
> Full version:
> 
> With named triples, a graph in the data model is a set of either
> asserted and/or named triples.

In this sentence, the word "either" in combination with "and/or" is
confusing. What exactly is the set that you are talking about here
supposed to contain? Either only asserted triples or only named
triples? Or did you want to say that it may contain both, asserted
triples and named triples?

> The named triples are not asserted in and of themselves (conceptually
> the names denote a *claim*), but another occurrence of the same
> abstract triple can also be asserted (conceptually that is a *fact*).
> There can only be one such asserted occurrence per graph (as in RDF
> 1.1), 

Regarding this latter part, I assume you say so because such an
"asserted occurrence" is manifested simply by having the triple
(abstract triple / triple type) directly as an element of the set of
triples that we call "RDF graph" and, since it is a set, the same
triple cannot be an element of the set twice. Correct?

If so, since this *one* "asserted occurrence" of a triple in a graph
does not have a name, we cannot make statements/annotations about it,
right?

Now I switch to quote from your first email in this thread:

> [...]
> Named triples can be represented as just triples, through a predicate
> for the lexical triple representation.
> 
> This named triple:
> 
>     <t> | <urn:x:s> <urn:x:p> "l"^^<urn:x:d> .

When you say "named triple", I assume you are using the term that you
have introduced in the wiki page with the terminology [1]. Since that
definition in the wiki is not very formal, here is a formal definition:

A 'named triple' is a pair (n,t) where n is an IRI or a blank node
called the 'name' of this named triple and t is an RDF triple.

Does this definition capture your intention?

If so, notice that the expression that you are writing above is not a
named triple but some proposed, Turtle-like serialization of a named
triple.
 
> 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?

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.


Now, I think these are enough questions and thoughts about your
proposal. So, I stop here.

Best,
Olaf

[1] 
https://github.com/w3c/rdf-star-wg/wiki/Triple%E2%80%90Edge-subgroup-proposals

Received on Friday, 12 January 2024 10:39:11 UTC