- From: Thomas Lörtsch <tl@rat.io>
- Date: Thu, 15 Aug 2024 18:02:53 +0200
- To: Olaf Hartig <olaf.hartig@liu.se>
- Cc: "franconi@inf.unibz.it" <franconi@inf.unibz.it>, "public-rdf-star-wg@w3.org" <public-rdf-star-wg@w3.org>
> On 15. Aug 2024, at 17:56, Olaf Hartig <olaf.hartig@liu.se> wrote: > > On Thu, 2024-08-15 at 15:41 +0000, Franconi Enrico wrote: >>> On 15 Aug 2024, at 17:25, Thomas Lörtsch <tl@rat.io> wrote: >>> >>> Am 15. August 2024 16:45:29 MESZ schrieb Franconi Enrico < >>> franconi@inf.unibz.it>: >>>> Before letting this discussion go too far, I want to be sure that >>>> we share the same assumptions. >>>> [0] assumes a CG-style notion of triple reification, which is not >>>> the one adopted by the current baseline. >>> >>> I don't think so: IIUC embedded triples in [0] are asserted and >>> referentially transparent types, wheras in the CG report they are >>> unasserted and referentially opaque types. >> >> [0] does not define a semantics for RDF*, nor simple entailment, but >> syntactically [0] has an abstract syntax mirroring the CG syntax, >> where there is no distinction between triple terms and triple >> reifiers; and SPARQL* in [0] is not based on BGP matching. > > SPARQL* in [0] is based on BGP matching, with the addition that it also > takes into account the triples that are contained within other triples > of the queried graph. > >> I’ve nothing against [0], I am only observing that is quite far away >> from our baseline. > > Yes, and you can happily ignore this branch of the email thread which I > only opened to quickly react to something that Thomas wrote about [0]. > It is not really relevant to the current discussions of our group. IMO it is because - it shows that querying triple and triple terms together has been deemed feasible already in RDF*/SPARQL* implementations - the fact that this poposal got so popular is a use case description in its own right .t > Best, > Olaf > >
Received on Thursday, 15 August 2024 16:03:03 UTC