Re: Two profiles: technical definition

Dear Enrico,

Thanks a lot for writing down these two definitions!

I have a few observations and questions related to these definitions:

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.

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'?

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.)

Thanks,
Olaf


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 10:41:42 UTC