- From: Olaf Hartig <olaf.hartig@liu.se>
- Date: Thu, 2 May 2024 12:18:17 +0000
- To: "franconi@inf.unibz.it" <franconi@inf.unibz.it>
- CC: "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
On Thu, 2024-05-02 at 11:32 +0000, Franconi Enrico wrote: > On 2 May 2024, at 12:41, Olaf Hartig <olaf.hartig@liu.se> wrote: > > > 1/ Your grammar for the abstract syntax in both of the profiles > > contains the restriction that triple terms cannot be nested. For > > instance, the following 3-tuple (having another 3-tuple as its > > third element which, in turn, has yet another 3-tuple as its third > > element) would not be an RDF triple that one may have in an RDF > > graph. > > > > (:r1, rdf:reifies, (:r2, rdf:reifies, (:s,:p,:o) ) ) > > > > I am not against this restriction. I just want to call it out > > explicitly. > > I noticed that myself this morning. I would be in favour of > arbitrarily nested triple terms, since (a) they make sense, (b) they > are well defined in the semantics, and (c) they wouldn’t add any > serious additional complexity in the algorithms (it is still pure > matching, albeit in a structure with no predefined depth). Fine with me as well. > > 2/ The definition of the notion of a 'model' in the "functional > > opaque" profile contains an additional formula within which it says > > IEXT(IS(rdf:edge)). This assumes that IS(rdf:edge) ∈ IP. Would it > > be useful to make this assumption explicit in point 3 of the > > definition of the notion of an 'RDF simple interpretation'? > > It would be redundant, since that condition plays a role only when > rdf:edge is actually used as a property in the graph, in which case > IS(rdf:edge) ∈ IP has to hold. Okay. > > 3/ Based on the definition of the "functional opaque" profile, it > > is still possible to have two different triple terms t1 and t2 > > (i.e., t1 != t2) that an RDF simple interpretation maps to the same > > resource, IL(SRE(t1) = IL(SRE(t2). Is that intentional? > > > > (I understand that the literals l1 = SRE(t1) and l2 = SRE(t2) are > > different---because SRE is bijective---but IL is not bijective, and > > shouldn't be.) > > I assume that this could be fixed by saying that this literal belongs > to a special ad-hoc datatype, where the interpretations of different > literals would be different. Given this response, I assume the answer to my question is: no, it was not intentional. I agree that such a fix is possible. A more formal way of capturing this fix would be to introduce a special subset of the set called 'literal', make this subset the co-domain of the SRE mapping, and extend the definition of the IL mapping such that the restriction of this mapping to the subset is bijective. -Olaf > cheers > —e. > > > > On Thu, 2024-05-02 at 07:05 +0000, Franconi Enrico wrote: > > > > > > (I repeat a previous email, which could have been lost within a > > > previous thread) > > > > > > In order to make the upcoming discussion more concrete and > > > technical, > > > I have written down the formal definition of two profiles in the > > > wiki: > > > RDF-star profile “transparent” (namely many-to-many transparent) > > > RDF-star profile "functional opaque” (namely many-to-one opaque) > > > They rely on two distinct properties - rdf:reifies and rdf:edge > > > (temporary name) - and on two distinct syntactic categories - > > > tripleTerm and opaqueTripleTerm. > > > Technically, they could be just merged into a unique profile, > > > which > > > actually could be RDF-star itself. > > > > > > —e.
Received on Thursday, 2 May 2024 12:18:25 UTC