Re: A question about referential opacity (again)

Hi Thomas,

> Am 25.10.2023 um 11:34 schrieb Thomas Lörtsch <tl@rat.io>:
> 
> Hi Dörthe,
> 
> 
> please forgive me that I skimmed this thread,
The threats became long, I totally understand :D

> not really reading it thoroughly right now, but this here strikes me:
> 
>> On 25. Oct 2023, at 00:31, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote:
> 
> […]
> 
>> Here is the point which surprised me that much, because in my opinion, N3 is not that different from SPARQL’s BGPs.  We only have a very strict difference between graph terms and graphs. 
> 
> Isn’t this a pretty considerable difference?! BGP matching is usually assumed to match against statements (contained in graphs, of course), but not graph terms as I understand you/N3 to define them.

But I was under the impression that this is also what we want to do here? Define graph terms? Wasn’t the goal to have something like

:s :p {:a :b :c. :d :e :f}.

As an extended version of RDF-star which covers graph terms instead of only triple terms?

> So it’s quite natural that intuitions clash if suddenly graph terms are introduced into a practice that is accustomed to a quite different behavior.

My point is, that I still do not see this „quite different behavior“.  If I have a graph 

:a :b :c. :d :e :f.

and a SPARQL query containing a graph expression in curly brackets {} like 

Select  *
Where {:a :b ?o}

Then this graph term {:a :b ?o} is closed. I look for the exact match to this closed expression {:a :b ?o}, I do not search for a whole graph which among other things contain {:a :b ?o}. My output will not contain any information about my triple :d :e :f.



> 
> In another mail a few days ago I pondered if graph types shouldn’t best be represented as datatyped RDF grah _literals_. And reading Pat’s post that Niklas cited yesterday [0] I’m even more likely to find that a good idea. Queryable literals of course, not just strings - that’s why it’s important that they are datatyped as RDF. But not asserted (also quite natural for literals - they only refer to themselves) and therefore IMO the perfect way to represent and talk about an abstract type. I imagine that this would cover any "logical" applications that want to work on the abstract level, and - separation of concerns - it doesn’t get mixed up with practices that are interested in tokens. 

Here I also need more time to think :) I will come back at that. 

Kind regards,
Dörthe


> 
> Does that make sense to you?
> 
> 
> Thomas
> 
> [0] https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Oct/0082.html

Received on Wednesday, 25 October 2023 09:54:37 UTC