Re: A question about referential opacity (again)

> On 25. Oct 2023, at 11:54, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote:
> 
> 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

Indeed, long threads can become threats ;-)

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

Part of my intention is to have graphs instead of triples.
But graph "terms", if that comes with a notion of "closed-ness" that i don’t really understand, I’m not sure about.
But I am sure that I want them to refer to tokens, not types.

Maybe all that doesn’t necessarily becomes visible in example queries.

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

But your output will also _not_ contain the triple from that graph, because that graph also contains other triples (namely ':d :e :f')? DO by "closedness" you mean that the graph contains _only_ such triples?

If that is so then it would definitely run counter popular intuitions about querying graphs. And I would not want that.

Otherwise, what does closedness mean? (Sorry if that is obvious from the thread and I missed it).

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

That would be great. If my interpretation above is correct, then I think the deeper problem - deeper, because it also touches why I so vehemntly oppose the CG semantics - is that such an approach introduces a very different way of thinking, a very different kind of application - into a "space" (for lack of a better term) which is already very prone to misinterpretation by its very nature (knowledge representation, the land of rabbit holes). Separation of concerns is good for everybody ;) It reduces the risk that a syntax will be used according to popular intuitions and not respecting its defined semantics (and because no other syntax is available to meet the popular demand). 


Best,
Thomas

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