Re: [Sem] Yet another formal semantics for RDF-star

> On 27. Mar 2023, at 20:42, Antoine Zimmermann <antoine.zimmermann@emse.fr> wrote:
> 
> Le 27/03/2023 à 19:42, Doerthe Arndt a écrit :
>> Dear Antoine,
>> I also have a firsts comments (also only after a quick look, so sorry in advance for the missinterpretation :) ):
>> 1. I noticed that you did not keep the semi-transparency (or however we call it, the term seems not really accurate) of blank nodes, meaning that for example
>> :a :b <<:c :d :e>>.
>> :c :p :o.
>> entails
>> :a :b <<*_:x *:d :e>>.
>> *_:y* :p :o.
> 
> You mean az-entails, right? I insist on being specific because we are discussing various options for entailment, each with subtle differences.
> In this case, yes.
> 
> 
>> I guess that is intended. So, my question: do we want that? Are there use cases where we would like to only entail these triples with „matching“ blank nodes? What are your thoughts about that?
> 
> I do not know what we want. I just propose a relatively simple, weak semantics that would capture the essence of reification, but without introducing a vocabulary. Maybe there are cases when you don't want the IRI "rdf:subject" to be denoting the relation that you envision between the reified triple and the subject resource. Maybe you want to define an extension that put more constraints on the relations between the subject, predicate and object.
> 
> Also, I believe that the semantics I propose is compatible with SPARQL-star (as defined currently) in the sense that, for any RDF-star graph Q if you do ASK { Q } on a dataset that only contains a default graph G, the answer is "true" iff G az-entails Q (this may have to be verified).
> 
> 
>> I guess currently SPARQL would not retrieve yes, if I do
>> ASK {:a :b <<*_:x *:d :e>>. *_:x* :p :o.}
>> on the graph
>> :a :b <<:l :d :e>>.
>> :c :p :o.
>> Would that be a problem?
> 
> This should not give you "yes" or "true".
> 
> 
>> 2. It is also interesting to note that <<_:x :p :o>> and <<_:y :p :o>> can have different meanings while in the graph
> 
> Just like _:x and _:y can have different meanings in RDF 1.1 Semantics.
> 
>> :a :b <<_:x :p :o>>.
>> :c :d <<_: x :p :o>>.
>> The expression <<_:x :p :o>> does only have one meaning and needs to pint to the same resource in both triples. So, if I make a statement like
>> :bob :smufs <<_:x :can :fly>>.
>> and try to give it „informal semantics“ (if that is even a thing), how do I need to see the blank node? Neither
>> „Bob smurfs that there exists an x which can fly“ nor „There exists an x about which bob smurfs that it can fly“
>> seem to be correct here based on my previous observations. So, how do you see these blank nodes. I guess I should not try to translate them as I just did, but how can I intuitively understand them in your theory?
> 
> If ":bob :smufs <<_:x :can :fly>>" is true, then we can say for sure, in az-semantics, that Bob smufs something, and this thing is related to the thing denoted by :can, and is related to the thing denoted by :fly. Anything else, we cannot say for sure. So maybe Bob smufs a statement, maybe Bob smufs an RDF triple, maybe Bob smufs a giraffe that has a colour called ":can" and that measures ":fly" metres. Who knows what Bob smufs?


We do at least know that Bob smu(r)fs _:something. We might know other things about that _:something from other statements. Wouldn’t we like to not loose that additional knowledge? Why cut that link?

While I do like (read: enthusiastically welcome) that the az-Semantics defines IRIs to be referentially transparent, I would very much prefer if blank nodes were too - for the very same reason: let the meaning of an embedded triple deviate as little as possible from what it means when asserted (and irrespective of the expense that might impose on the formalisation). 

After all most of the time an embedded triple will be used to refer to an asserted triple of the same form, and with such uses come assumptions, expectations and intuitions. Those to be expected intuitions of users should guide the semantics, as otherwise it will have a very hard time to be actually used (and useful).

+homas


> --AZ
>> Kind regards,
>> Dörthe
>>> Am 27.03.2023 um 19:02 schrieb Franconi Enrico <franconi@inf.unibz.it <mailto:franconi@inf.unibz.it>>:
>>> 
>>> I looked at it carefully. This seems to characterise more or less the model theory of what I call syntactic predication, which is more or less the current definition of <<.,.,.>>.
>>> Some comments - tell me if I’m wrong.
>>> Some difference I note is that a syntactically embedded triple would still entail the truth of the triple itself, which probably is not intended, and that the reification “implements” the full semantic predication (ie., it would be fully transparent).
>>> Moreover, there is still the open discussion about injectivity, and the interoperation, if desired, with the TEP and/or with the full semantic predication.
>>> cheers
>>> —e,
>>> 
>>> 
>>>> On 27 Mar 2023, at 18:08, Antoine Zimmermann <antoine.zimmermann@emse.fr <mailto:antoine.zimmermann@emse.fr>> wrote:
>>>> 
>>>> Le 27/03/2023 à 17:37, Peter F. Patel-Schneider a écrit :
>>>>> It would be useful to have some more explanation and some examples.
>>>> 
>>>> Yes, it is brutally asserting the definitions and nothing else.
>>>> 
>>>>> From my quick read this appears to be very lose to to using RDF reification plus uniqueness of triples.
>>>> 
>>>> Yes. The one benefit that I see is that it does not require introducing a vocabulary that would "reserve" some URIs.
>>>> 
>>>>> In the Satisfaction section it appears that either a nor J[a] is defined for blank nodes.
>>>> 
>>>> Damn, I sometimes used bold face T as if it meant the set of all terms, while it is in fact defined as the set of RDF-star triples.
>>>> 
>>>> α should be defined on "B ⋃ T ∖ Gnd".
>>>> There is an unfortunate copy-paste error before the colon of the 1st paragraph in section "az-Satisfaction"("𝓘[α](t) = : T → Δ" should be "𝓘[α]: T → Δ" and the second item of the first bullet list of this section should have "B ⋃ T ∖ Gnd" instead of "T ⋃ Gnd".
>>>> 
>>>> I'll correct that.
>>>> 
>>>> --AZ
>>>> 
>>>> 
>>>>> peter
>>>>>> On 3/27/23 09:09, Antoine Zimmermann wrote:
>>>>>> This is mostly for the semantics task force.
>>>>>> 
>>>>>> I wrote this:
>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.emse.fr%2F~zimmermann%2FW3C%2FRDF-star-semantics%2F&data=05%7C01%7Cfranconi%40inf.unibz.it%7C0af42a10bb17440a339608db2edd762c%7C9251326703e3401a80d4c58ed6674e3b%7C0%7C0%7C638155300922073245%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6uRqnTJKbGqC0B321HKqZRihQL0MdSw55mCJars9kFg%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.emse.fr%2F~zimmermann%2FW3C%2FRDF-star-semantics%2F&data=05%7C01%7Cfranconi%40inf.unibz.it%7C0af42a10bb17440a339608db2edd762c%7C9251326703e3401a80d4c58ed6674e3b%7C0%7C0%7C638155300922073245%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6uRqnTJKbGqC0B321HKqZRihQL0MdSw55mCJars9kFg%3D&reserved=0>
>>>>>> 
>>>>>> The idea is that embedded triples are interpreted as arbitrary resources and the resources denoted by the subject, predicate, and object of an embedded triple are connected (semantically) to the embedded-triple-resource via 3 properties that depend on the interpretation.
>>>>>> 
>>>>>> Now, please comment and destroy this proposal :)
>>>> 
>>>> -- 
>>>> Antoine Zimmermann
>>>> ISI - Institut Henri Fayol
>>>> École des Mines de Saint-Étienne
>>>> 158 cours Fauriel
>>>> 42023 Saint-Étienne Cedex 2
>>>> France
>>>> Tél:+33(0)4 77 42 66 03
>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.emse.fr%2F~zimmermann%2F&data=05%7C01%7Cfranconi%40inf.unibz.it%7C0af42a10bb17440a339608db2edd762c%7C9251326703e3401a80d4c58ed6674e3b%7C0%7C0%7C638155300922073245%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Uq9jD3AqFfA1fbVNzL6X3Fbrw49ESs6uHuBe3jC1Ago%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.emse.fr%2F~zimmermann%2F&data=05%7C01%7Cfranconi%40inf.unibz.it%7C0af42a10bb17440a339608db2edd762c%7C9251326703e3401a80d4c58ed6674e3b%7C0%7C0%7C638155300922073245%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Uq9jD3AqFfA1fbVNzL6X3Fbrw49ESs6uHuBe3jC1Ago%3D&reserved=0>
>>>> 
>>>> 
> 
> -- 
> Antoine Zimmermann
> ISI - Institut Henri Fayol
> École des Mines de Saint-Étienne
> 158 cours Fauriel
> 42023 Saint-Étienne Cedex 2
> France
> Tél:+33(0)4 77 42 66 03
> https://www.emse.fr/~zimmermann/
> 
>

Received on Monday, 27 March 2023 19:38:41 UTC