Naming conventions [was: Re: owl:sameAs/referential opacity Re: Can RDFstar be defined as only syntactic sugar on top of RDF (Re: weakness of embedded triples)]

> On 20. Nov 2020, at 00:03, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> 
> On 11/19/20 5:04 PM, thomas lörtsch wrote:
>> 
>>> On 19. Nov 2020, at 19:06, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>> 
>>> I think there is still a problem in this discussion with underdefined
>>> foundational terms, notably "triple type".
>>> 
>>> There are two documents that, in my opinion, provide foundations for RDF*. 
>>> There is the original technical report "Foundations of an Alternative Approach
>>> to Reification in RDF" and there is RDF* and SPARQL* at
>>> https://w3c.github.io/rdf-star/rdf-star-cg-spec.html.  The term "triple type"
>>> does not occur in the former and only occurs in the latter without definition.
>>> 
>>> Please can we only use technical terms that are defined in one of these
>>> documents or that have an accompanying definition that is based on terms in
>>> one of the above documents?
>> I understand that my sometimes quite naive inquieries must be frustrating to follow for people that are fluent in the terminology and understand properly what they are talking about. I’m trying to understand what RDF* is not on its own, with the terms the paper and the spec use, but in comparison to RDF reification. Pat in an earlier mail in this thread, cites the published semantics document (https://www.w3.org/TR/rdf11-mt/#reification):
>> 
>> "The subject of a reification is intended to refer to a concrete realization of an RDF triple, such as a document in a surface syntax, rather than a triple considered as an abstract object."
>> 
>> I understand that what I called in a misguided stylistic attempt an "actual assertion" and then a "triple occurrence"  and sometimes a "triple token" is what the RDF spec calls "a concrete realization of an RDF triple". OTOH I understand the term "triple type" as referring to the same concept that the RDF spec calls "a triple considered as an abstract object".  Is that good enough as a shared vocabulary or is it not clear if terms from the RDF spec are appropriate to describe concepts of RDF*?
>> 
>> I take it from Pierre-Antoines last answer (thanks for your patience, pa!) that the subject of an RDF* annotation is  what the RDF spec calls "a triple considered as an abstract object". That is a description that I can wrap my head around and work with. I hope it’s right.
>> 
>> Thomas
> 
> 
> If there is already terminology in the RDF documents that fits, then why not
> use that.
> 
> For example, triple is a core term of RDF, consisting of three components in
> the abstract syntax document.  If you mean triple, just say "triple".  If you
> want to call out that the triple is in some RDF graph, just say that.  If you
> want to refer to a triple in some system that manipulates RDF triples, then
> just say that this is what you mean.
> 
> If you mean an occurrence of a triple in some document, then say that. 

If you've got a general concept and a few applications, one of which applications is bound to be the widely predominant one and the wildly predominant subject of discourse especially among practitioneers in the field (as opposed to experts who can be expected to be fit in any kind of nomenclatura) then it is a very good idea to name the predominant use with a short and catchy phrase and any other use, especially the more theoretically relevant ones with clearly differentiated and probably longer terms, and provide a second (probably longer) term for the predominant use case to clearly differentiate it from anything that the unaware practitioneer might confuse and conflate it with. Reserving the short and catchy phrase "triple" for the abstract thing, that is almost never talked about (without even providing a more differentiating option like "abstract triple" to avoid misunderstandings in certain situations) and naming the concrete application, that is almost always the topic of discourse, "triple in some RDF graph", "triple in some system that manipulates RDF triples", "occurrence of a triple in some document" is the worst naming convention possible. And it is ignored outright anywhere, in almost every scientific paper discussing the semantic web even. "Triple" is the term that everybody uses to refer to triple occurrences in graphs, systems, documents, whatever - and justifiably so.

Thomas


> So if you wanted to say something about RDF reification you would say that the
> RDF triples:
> 
> <X rdf:type rdf:Statement > <X rdf:subject ex:a >  < X rdf:predicate ex:b> <X
> rdf:object ex:c>
> 
> where X is either a blank node or an IRI, is the X reification of the RDF triple
> 
> <ex:a ex:b ex:c>
> 
> Note that I'm using curies as standins for IRIs which is strictly speaking not
> kosher but can easily be fixed up.
> 
> 
> You could then define an extended Turtle syntax that permitted (extended)
> triples as subjects or objects of (a.k.a., embedded in) other (extended)
> triples and define a mapping from this extended syntax to RDF graphs that
> replaced each occurrence of an extended triple embedded in another extended
> triple by a fresh blank node B and added the B reification of the triple to
> the resultant graph and worked as in regular RDF otherwise.  (Note that the
> replacement has to be done from the inside out so as not to create new
> occurrences of embedded triples.)  This results in something similar to RDF*,
> which could perhaps be called RDF-fresh.
> 
> Changing how the replacement is done gives different behaviour.  Two
> interesting variations are to have an injective mapping from triples to either
> blank nodes or IRIs and use the results of this mapping instead of the fresh
> blank node above.  (You want the blank nodes to not occur elsewhere in the
> graph and you almost certainly want the IRIs to not occur elsewhere in the
> graph.)  I believe that the first variant here is the original RDF*.  The
> second variant is mostly referentially opaque.  An even more opaque variant
> can be obtained by using a fresh IRI for each occurrence.
> 
> This gives something to talk about that doesn't underdefined terms like triple
> token and triple type but nonetheless distinguishes between a triple and an
> occurrence of a triple in a document.
> 
> peter

Received on Friday, 20 November 2020 00:09:05 UTC