Re: A question about referential opacity (again)

> On 21. Oct 2023, at 15:59, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> Graph terms add a new level of complexity for semantics.
> 
> What kind of semantics is to be used?  Does it have to be modal?

Same for triple terms, and the same answer too.
(IMO that talk of "modal" is a distraction. Annotations just add more detail, period.)

> What does a graph term denote?  The graph?  Some idealization of the graph?  A set of interpretations?

Same for triple terms, and the same answer too.
(IMO in most cases the term needs a name to be useful)

> What entailment relationship is to be used between graph terms?  Equality? Entailment?  Which entailment?  Canonicalization?

Same for triple terms, and the same answer too.
(IMO in some cases it would be useful to provide a way to talk about terms as types)

> Are graph terms (always) named?  What does a named graph term denote?

Same for triple terms, and the same answer too.
(IMO yes, and the name denotes the pair name/graph (IIUC that’s Pat’s construction in Named Graphs 2005))

> Graph terms add a new level of complexity for syntax.

I really can’t see the added complexity of

 :a :b :c .
 :d :e :f  .
 << :a :b :c . :d :e :f >> :y :z .

versus 

 :a :b :c .
 << :a :b :c >> :y :z .
 :d :e :f  .
 << :d :e :f >> :y :z .

and even less for 

 []{ :a :b :c . :d :e :f  } :y :z .

or

 [:X]{ :a :b :c . :d :e :f  }
 :X :y :z .

Just imagine a real example, with a real graph, made up of at least a handful of statements. The nested graph syntax wins hands down, with the triple term syntax a distant third.

> Are graph terms disjoint from triple terms?  Is there a level of compliance for just triple terms?

IMO No
IMO No need

> Are named graph terms additive in all syntaxes?  (They have to be additive in quad syntaxes if the fourth element is the name of a graph term.)

I don’t understand.

> Graph terms add a new level of complexity for uses.

To the contrary: with graph terms if you have a small number of triples to annotate, you don’t need to decide if you use named graphs or triple terms. When you query for annotations (eg the source) you don’t have to query for both named graphs and triple terms just to be sure you don’t miss anything.
So everything is decidedly more predicatble. That’s a huge benefit.
And have you yet tried to record provenance of a not minimal set of triples with RDF-star?
You will get the same bitching about triple count as with standard reification (and IMO rightfully so) and you will get all kinds of evasive manouvers, and in the end (maybe a decade from now): graph terms.

> What are graph terms to be used for?  Events?  Provenance?  Beliefs?  Change? Time? Knowledge?  Other modals?

Same for triple terms, and the same answer too.
(IMO the answer is as easy as imperative: anything.)

> No matter what benefits graph terms provide I see lots of extra complexity. Although there are still outstanding issue for triple terms, many issues have already been decided.  Switching to graph terms opens up all issues again.

I disagree about the _added_ complexity. The problem is complex for triples and graphs alike. But going for graphs makes the correct use of whichever construct we come up with much less ambiguous in practice, and that IMO is an advantage that can hardly be overestimated.

Thomas

> peter
> 
> 
> 
> On 10/21/23 09:15, Thomas Lörtsch wrote:
>>> On 21. Oct 2023, at 14:22, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>> 
> [...]
> 
>>> PPS:  There are other ways of obtaining opacity.  If the working group switches to graph terms the kind of semantics described above might not be adequate and some other treatment might have to be used.
>> I was meaning to ask you about that, as you voiced such concerns in the WG meeting last week. I just can’t see which profound changes to the semantics a switch from Triple Terms to Graph Terms would incur or require, so I assume those are technicalities. The only "issue" I can see is the need for transparent blank nodes going away, but that should make things easier, not harder.
>> Anyway, I think the increase in usability far outweighs any additional effort in adjusting the semantics (although, of course, I’m not the one who would have to adjust them ;-), but that topic probably should be discussed in a separate thread.
>> Thomas

Received on Saturday, 21 October 2023 14:35:45 UTC