- From: Olaf Hartig <olaf.hartig@liu.se>
- Date: Fri, 12 Jan 2024 10:39:03 +0000
- To: "lindstream@gmail.com" <lindstream@gmail.com>, "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
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