Re: Slides: Talking About Occurrences

Dear Niklas,

I also had a look to your slides and now wonder where you stand.

If I get you correctly here, you argue that you would like to interpret RDF-star triples in a way that in

:s :p <<:a :b :c>>.
:k :l <<:a :b :c>>.

the two <<:a :b :c>> refer to different resources in the domain of discourse. You call that the "interpretation as tokens“. If I read the text of Pat Hayes on slide 7, I see that he is using the relation type vs. token as follows: for him the type is the abstract graph and the token is the concrete representation. As he talks about named graphs, he uses the name to distinguish between two tokens, such as in:

:g1 {:a :b :c}
:g2 {:a :b :c}

So, here, the case is rather easy and even the semantics, which maps tokens to types will not have problems because :g1 and :g2 are easy to distinguish. In my view, if we have

:s :p <<:a :b :c>>.
:k :l <<:a :b :c>>.

we have the exact same token twice, namely <<:a :b :c>>. Of course you could understand this as syntactic sugar for reification which then would allow you to have two different resources, if you want (they could still be the same though). But what stops you from taking for example the iris as types? Everything would be broken in that case, I know. But still, to me this looks like a random choice to take triple terms as tokens while iri terms are types.

What also puzzles me  is: If you go for types in your sense, how does this play together with your wish for referential transparency? If we have that :a and :a27 refer to the exact same resource, how would you argue that 

:s :p <<:a :b :c>>.

Is the same as 

:s :p <<:a27 :b :c>>.

while the first <<:a :b :c>> is not even the same as the second? Or how do you see the opacity vs. transparency here? I ask, because I saw all the texts you quoted as a reason why we needed opacity (and then I realized that I should not use quotes to make my point since there is interpretation involved :D, therefore I do not play the „quoting game“ and ask instead what YOU think).

At the moment, I really think that you want syntactic sugar for reification, but most likely I am wrong (I remember that you said that was not the case?).

Kind regards,
Dörthe
 

> Am 27.10.2023 um 12:06 schrieb Antoine Zimmermann <antoine.zimmermann@emse.fr>:
> 
> Niklas,
> 
> 
> A few comments about your slides (not necessarily about your proposal):
> 
> First, the good things: RDF reification is indeed under-used, but it is used. Especially, it has been used in significant datasets like uniprot when the default syntax for RDF was RDF/XML. RDF/XML has syntactic sugar for reification, which makes it super easy to write. One reason people don't like reification is because it is verbose and cumbersome. But RDF lists are also verbose and cumbersome if written as triples. Yet, with the right syntax, good practices, and dedicated primitives in programming, they are well accepted and well supported. The same could be true with reification. So, yes, "quoted triples" as a way to simplify the use of standard RDF reification is an option that should be on the table. But the big problem is that the semantics is not constraining at all, and people may have completely different practices in the way they use reification. However, as opposed to named graphs, RDF reification has a normative semantics, although it is very weak.
> 
> 
> Second, the criticism, in details:
> 
> Slide 6 has the title "RDF 1.1 Concepts" and subtitle "on reification", but the text you put on the right is from RDF Schema. "Concepts" don't say anything about reification. Moreover, this text is in a section that is not normative. Formally, the semantics of reification does not imply that a reified triple is a token or anything. According to the standard, one could interpret a reified triple as the triple itself and it would not violate anything normative.
> 
> Then in Slide 7, what is written is Pat Hayes's idea of a named graph. But as far as the standards are concerned (SPARQL 1.0, SPARQL 1.1, and RDF 1.1), named graphs are *only* pairs (n,g) and that's all. You may interpret this as a token of a graph with a name if you want, but again, this is not normative and there are other ways to interpret it.
> 
> In Slide 24, it is written "A triple is identified with the singleton set containing it", and a subtitle says "RDF 1.1 Semantics". Clearly, an element and the singleton that contains it are never the same, but they may be identified in certain contexts. I do not understand to which context you refer here. The mention of RDF 1.1 Semantics is misleading because RDF 1.1 Semantics does not have this identification. In fact, quite the opposite: if they were identified, then:
> 
> { <me> <wears> _:b . _:b a <Hat> }
> 
> would be identified with
> 
> {{<me> <wears> _:b}, {_:b a <Hat>}}
> 
> But these two sets mean different things. The second one does not imply the first one. First one says "I wear a hat", while second one says "I wear something. There exists a hat."
> 
> Slide 30: Again, "The <name, graph> pair is a token of its mathematical graph." is one way of interpreting the pair. Imagine I have a pair (iri, n), where iri is an IRI and n is a natural number. Would you interpret this as a token for the mathematical number n? For instance, instead, if iri is a DOI, n could be the number of times the document was printed.
> 
> Also, "This token, which is denoted by this name" is your interpretation. "Denote" is formally defined in RDF 1.1 Semantics: https://www.w3.org/TR/rdf11-mt/#dfn-denote, so when you use this term in the context of RDF, it suggests that you talk about what RDF Semantics says. But RDF Semantics does not say that the graph name denotes anything in particular.
> 
> Slide 34: I don't understand or I simply disagree with some of the statements: "...nested graphs? (...) Requires “graph literals” (...)" -> I don't see how this follows from that.
> 
> "… graph terms? Same problem as for triple terms -
> these are abstract mathematical objects denoting
> themselves." -> graph terms are just a syntactic structure. This does not imply anything about what they denote or not.
> 
> 
> 
> Additionally, there are parts where it is hard to understand what you mean. Your spoken words yesterday explained some things but sometimes even with your verbal presentation, I had trouble figuring out what your proposal(s) consist(s) in exactly.
> 
> 
> 
> --AZ
> 
> Le 26/10/2023 à 20:37, Niklas Lindström a écrit :
>> Dear all,
>> Here are the slides I presented at today's teleconference.
>> Best regards,
>> Niklas
>> (PS. Escher's Dragon is pixelated to avoid copyright issues.)
> 
> -- 
> Antoine Zimmermann
> École des Mines de Saint-Étienne
> 158 cours Fauriel
> CS 62362
> 42023 Saint-Étienne Cedex 2
> France
> Tél:+33(0)4 77 49 97 02
> http://www.emse.fr/~zimmermann/

>

Received on Friday, 27 October 2023 13:56:27 UTC