Re: defining the semantics of lists

> On 19. May 2020, at 00:29, Patrick J Hayes <phayes@ihmc.us> wrote:
> 
> Focussing on the key issue:
> 
>> On May 18, 2020, at 4:06 PM, thomas lörtsch <tl@rat.io> wrote:
>> 
>> 
>>> On 18. May 2020, at 18:43, Patrick J Hayes <phayes@ihmc.us> wrote:
>>>> On May 18, 2020, at 11:26 AM, Cory Casanave <cory-c@modeldriven.com> wrote:
>> 
>>>> We have an existing capability for managing sets of facts - the graph. The graph is already a "closed" set of facts. What we can't express is that a graph may be complete for a specific set of types or a specific set of predicates about a specific set of types. With that capability we could express a closed set - something that is REAL in our world. 
>> 
>> That sounds like a good approach.
>> 
>>> Yes, that ability – to say explicitly, in the data, that a certain set of data is complete wrt some kinds of information – would enable closed worlds to be reasoned about in an open-world reasoning framework. It is not easy to see how to do this, however. I have thought about this on and off for about a decade or more, and have not come up with a workable general way to do it. 
>> 
>> Would very fine grained Named Graphs (*) help? Rather Named Triples that can be grouped to Graphs in arbitrary ways (virtual/nested/overlapping/fluid Named Graphs if you want). May no scale super well but let’s not do early optimization. 
> 
> I do not follow what you mean here by ‘fine grained'. Named graphs would certainly help, indeed are arguably essential. 

I mean defining triple per triple to what graph it belongs. That way you can have arbitrarily nested and overlapping graphs - which you’ll need when you put all sorts of information (like closedness, provenance, context etc etc) in the graph layer

>>>> A "list" is then just an ordering of the things in a closed graph.
>>> 
>>> Nope, that does not work. Just listing the things is not enough, you also need a way to say what kinds of facts are being ‘closed’. For example, a list of employees might be complete in the sense that it lists them all, but not in the sense that it says everything that can be said about them. 
>> 
>> I’m quite puzzled by this objection. The relation is employeeOf, not everythingThatCanBeSaidAboutEmployeeOf.
> 
> Yes, but where is it specified that the graph is ‘closed’ (ie supports closed-world reasoning) for assertions involving employeeOf but not for, say, BrotherOf? That is the what is needed, a way to say ’the data in this graph is complete for assertions of <this kind>'. How do we specify <this kind>?

I see. Well, that sure needs some thinking (and it’s late here already) but on first sight it doesn’t seem unsolvable.

> Pat
> 
>> What logic mechanism are you referring to here? If we are up against such greedyness then we are in a much worse situation than I thought.
>> 
>> 
>> Thomas
>> 
>> 
>> (*) with a little vocabulary addition that allows to refer to Named Graphs with sound, denotational semamtics
> 
> The semantics of named graphs has been developed quite throughly in https://www.researchgate.net/publication/234804495_Named_Graphs_Provenance_and_Trust

Yes, I mean a solution to the very practical problem that one can unambiguously refer to graphs in queries (through the FROM and FROM NAMED syntax) but not when one wants to annotate them. The dataset spec is the problem, not the paper.


Thomas

Received on Monday, 18 May 2020 22:55:25 UTC