Re: Unified proposal for embedded triples (as per today's meeting)

Hi Enrico, Dörthe,


a good bit of your discussion is quite uncomprehensible to me (I guess that qualifies me as "normal", but I had a hunch already … ;-) However, I did manage to read it all and added a few comments inline, below. Maybe it helps.


> On 8. Mar 2023, at 14:20, Doerthe Arndt <doerthe.arndt@tu-dresden.de> wrote:
> 
> Dear Enrico,
> 
> Thank you for your answer.  Some comments below.
> 
>> 
>>> If we have that :teaches is an equivalent property to :givesClass (and if equivalent property is  covered in our semantics), we can still conclude that from 
>>> 
>>> << :john :teaches :cs101 >> rdf:type :teaching ;
>>>                           dct:Location dbr:Stanford_University ;
>>>                           dct:PeriodOfTime :1st-term-2022 .
>>> :john :teaches :cs101.
>>> 
>>> that
>>> 
>>> << :john :givesClass :cs101 >> rdf:type :teaching ;
>>>                           dct:Location dbr:Stanford_University ;
>>>                           dct:PeriodOfTime :1st-term-2022 .
>>> :john :teaches :cs101.
>>> 
>>> We can do similar things with the subject and the object of the triple if we know that they are equivalent to other triples. But what happens if we have that the whole triple is equivalent to another one? For example, if we know that 
>>> 
>>> :john :teaches :cs101.
>>> and 
>>> :cs101 :isTaughtBy :John.
>>> 
>>> have the exact same meaning. How would we get that 
>>> 
>>> << :cs101 :isTaughtBy :John. >> rdf:type :teaching ;
>>>                           dct:Location dbr:Stanford_University ;
>>>                           dct:PeriodOfTime :1st-term-2022 .
>>> 
>>> It does not follow directly from the current semantics.
>> 
>> Well, well, well.
>> You have first to specify exactly what is the semantics of “have the exact same meaning” or "the whole triple is equivalent to another one", and how to possibly express it.
> 
> I see your point. When I wrote the sentence, I was actually thinking of the extension and somehow expected that two equivalent properties also have the same interpretation, but yes, of course these are two different things. 
> 
> I now wonder what a user would expect.

I don’t see Enrico’s point. What I expect is very simple: when two statements mean the same thing then I expect annotations that hold on one of them to also hold on the other one. What could be wrong about that expectation? When should it in your or Enrico’s view not hold?

> Maybe we can make some examples of entailment and non-entailment together with your semantics proposal to discuss that with the whole group, because I think these would be easier to digest for many people and we would learn a lot about expectations and thereby indirectly something about use cases.  Maybe it would even be nice to have a questionnaire or something like that and let people fill in their expectations (we can still opt against certain points of view, but I really wonder which derivations are „intuitive“ here).
> 
> I did not have the event-based view (till now) and therefore wondered a lot about the entailments and non-entailments (which make sense if you see the things as events but not if you see them for example as just statements). I see that I understood the semantics right, but was surprised by the intended non-entailment.
> 
>> Let’s try some possibilities.
>> 
>> If we assume that “having the exact same meaning” is stated (e.g., in OWL) as 
>> 
>> IEXT(:teaches) = IEXT^{-1}(:isTaughtBy)
>> 
>> then it would not follow from the semantics.
>> But this is to be expected, since the above axiom constrains the two properties only in terms of their extensions, but not in terms of their intentions - namely the names of the properties themselves. The name of the property, as we know, is one of the three elements on which reification depends, together with the subject and the object of the embedded triple.
>> 
>> Let consider the following extension of your example, which shows my point in a clearer way.
>> Suppose that we are modelling a university where only and all the professors contributing to the syllabus of a course can teach that course, so that we write the constraint:
>> 
>> IEXT(:contributesToSyllabusOf) = IEXT(:teaches) = IEXT^{-1}(:isTaughtBy)
>> 
>> Clearly, the these two properties induce completely distinct events (i.e., teaching and contributingToSyllabus), and indeed the above derivation is not expected at all, and rightly so. The reason, as I was saying, is that inclusion of extensions of pairs of subjects and objects does not state at all that we are talking about the same property.
>> Note that the extended example is not equivalent to:
>> 
>> :contributesToSyllabus owl:sameas :teaches.
>> 
>> since this latter statement says that 
>> 
>> I(:contributesToSyllabusOf) = I(:teaches)
>> 
>> which says that the two properties are really interpreted as the same property in the interpretation, and therefore in this case their reifications would be the same and would denote the same event, which is unwanted.

It seems to me that the example is broken: IEXT(:contributesToSyllabusOf) is NOT equal to IEXT(:teaches) according to the description given - "all the professors contributing to the syllabus of a course can teach that course". The description says that professors in IEXT(:contributesToSyllabusOf) CAN teach courses, not that they DO teach courses. If the axiom states that they DO, although according to the description given they merely CAN, then it is no wonder that the results are un-intuitive (w.r.t. the description).
> 
> I agree, but wondered whether if two properties have the exact same extensions in all their models (for example we because we claim that they are equivalent: p1 rdfs:subpropertyOf p2. p2  rdfs:subpropertyOf p1) would have the same interpretation, but I see that this is not necessarily the case or that at least it is not imposed by rdfs-semantics.  For the use case as you put it here, it would also not be necessary.
> 
>> 
>> So, let’s try some other way to state that :john :teaches :cs101. and :cs101 :isTaughtBy :John. “have the exact same meaning”.
>> In my papers on reification (e.g., [1] and [2]), I show that (semantic) reification (in DL, UML, E/R, ORM) is based on the ability to represent a fact with semantically meaningful explicitly named roles.
>> This means that we should have the ability to write reified triples with “custom” semantically meaningful property names, as follows:
>> 
>> _:t1 :teaches-subject :john.
>> _:t1 unstar:property :teaches.
>> _:t1 :teaches-object :cs101.
>> _:t2 :isTaughtBy-subject :cs101.
>> _:t2 unstar:property : isTaughtBy.
>> _:t2 :isTaughtBy-object :john.
>> 
>> If we then write the appropriate equalities:
>> 
>> :teaches-subject owl:sameas :isTaughtBy-object.
>> :teaches-object owl:sameas :isTaughtBy-subject.
>> _:t1 owl:sameas _:t2.
>> 
>> we get eventually the result you want!

It seems to me that you are reinventing the wheel of OWL reflexive properties for the unstar mapping, but what for? A reification is not the same as the thing it reifies, so why bother with this problem? To repeat my remark from above: it’s a statement as a whole that is considered to have the same meaning as some other statement as a whole. That should have consequences w.r.t. annotations on them, i.e. they should be valid on both of them. I would not expect it to also have consequences on the vertices of those statements because the annotations don’t address those vertices.

I think there is a deeper problem lurking here: a distinction between annotations that modify/qualify a statement on the inside, in effect creating a subtype, and those that merely describe it as a type, adding something on the outside. The latter work on reifications. Does this make sense?

>> However, we can not deal with “custom” property names for reification in RDF-star, so we can conclude that there is no way in RDF and derivatives to even state something like “have the exact same meaning”.
> 
> The things you show here can not be done in the star-reification but it would be possible to extend the semantics itself to get there (for example by stating that if p1 is the inverse property of p2, then IT(I(s),I(p1),I(o))=IT(I(o), I(p2),I(s)), and some more care for details of course).   
> 
> Whether it is what we want is another question… 
> 
> My point was that it should be clear what follows and what not. Not all entailments for triples hold for quoted triples, take the equivalent property from above as example (the two subproperty declarations, to be more precise). I see that I have certain expectations and you also have some and we can convince each other or not, but I would prefer to get a better view on the „normal“ user (sorry for saying that you are not normal, I hope that it helps here that I am not either ;) ). 
> 
> So, without your explanation, I was expecting that equivalence (in the sense of same extensions) should lead to same interpretations if we allow some form of transparency. But I now see that there can be different levels of „transparency“  and that we should be explicit about what we want and what we would not want.
> 
>> 
>> My conclusion is that semantic reification is indeed fully “semantic” and fully “transparent” (whatever this last word actually means), but RDF, RDFS, OWL are languages which are not tailored to express directly the kind of knowledge of your example. But you could do it, for example, by using RDF-surfaces :-)
> 
> I would still argue that we are somehow bound to a structure, but I learned from you that this is not necessarily bad.  
> 
>> 
>>> As an open question, I would also like to know, how you’d deal with logical consequences. So, what if :teaches is a sub property of :isInvolvedInCourse. Would we get any derivation triple containing a quoted triple or not? Do we want 
>>> 
>>> << :john :isInvolvedInCourse :cs101 >> rdf:type :teaching ;
>>>                           dct:Location dbr:Stanford_University ;
>>>                           dct:PeriodOfTime :1st-term-2022 .
>>> :john :isInvolvedInCourse :cs101.
>>> 
>>> For this last example I have no opinion yet (apart from: no would be easier) and I think it would depend on the use cases. So,  to keep it open: how far should our referential transparency go?
>> 
>> In semantic modelling it would be wrong to get such a derivation.

I see again a problem with the example: an annotation on a property is necessarily valid also for all sub-properties, but not necessarily for all super-properties. If the example used e.g. :eloquentlyTeaches as a sub-property of :teaches, then the annotation would be fine:

<< :john :eloquentlyTeaches :cs101 >> rdf:type :teaching ;
                          dct:Location dbr:Stanford_University ;
                          dct:PeriodOfTime :1st-term-2022 .
:john :eloquentlyTeaches :cs101.

>> Indeed, as I said above, stating that a property B is a sub-property of a property A implies ONLY that the pairs of resources denoted by B are a subset of the pairs of resources denoted by A, namely:
>> IEXT(B)⊆ IEXT(A)
>> written as
>> B rdfs:subproperty A.
>> and nothing is said about the property “names”.
>> 
>> Consider the example (taken from [1] and [2]) of modelling taxi drivers in Malesia, where a taxi driver MUST own her own taxi:
>> 
>> :drivesTaxi rdfs:subproperty :ownsTaxi.
>> 
>> where it is clear that an event of driving a taxi is NOT an event of owning a taxi…
> 
> Such a derivation would make sense if we’d use it to express some kind of knowledge
> 
> :bob :knows << :john :drivesTaxi :taxi1234 >>.
> 
> would then imply 
> 
> :bob :knows << :John :ownsTaxi :taxi1234 >>.
> 
> So, in some contexts, the derivation could make sense and in others not.

It seems to me that the examples driving this conclusion were faulty. Can we say that "some" and "others" refers to correct and incorrect application of subsumption and inheritance relations, or is there something more that I missed?


Best,
Thomas



> In your really specific interpretation where you see quoted triples as events it does not make sense. If we see quoted triples in the provenance context, the interpretation as you have it here does not make sense either since we would not even want to have any derivations if two names refer to the same resource. I know that you took care of that with your alternative semantics. The only argument I want to make here is that this semantics is - just as the syntactical view - tailored to a use case. Are we sure that your three semantics cover everything people want to do?  Which use cases do we want to cover and which not?
> 
> 
> Would you want to start a separate document about expected or not expected derivations or should we wait with that till you work out the three semantics you have in mind? Of course I can write down the examples we had so far (and a few more) if we plan a discussion. I think it would be really nice to have this „by example“ discussion at some point.
> 
> Kind regards,
> Dörthe
> 
>> 
>>> Kind regards,
>>> Dörthe
>> 
>> It is a pleasure to discuss technical details with you, please go on asking. This gives me the opportunity to clarify the ideas behind reification even more.
>> cheers
>> —e.
>> 
>> [1] Alessandro Artale, Enrico Franconi, Rafael Penaloza, Francesco Sportelli: A Decidable Very Expressive Description Logic for Databases. ISWC (1) 2017: 37-52.
>> [2] Alessandro Artale, Enrico Franconi: Towards a Logical Foundation of Reification in Modelling Languages. In: Ontology Makes Sense- Essays in honour of Nicola Guarino, IOS Press 2019: 242-256.
>> 
>> 
>>>> Am 03.03.2023 um 08:29 schrieb Franconi Enrico <franconi@inf.unibz.it>:
>>>> 
>>>> Hi Olaf,
>>>> sure, no problem, I’ll work on that.
>>>> —e.
>>>> 
>>>>> On 3 Mar 2023, at 01:04, Olaf Hartig <olaf.hartig@liu.se> wrote:
>>>>> 
>>>>> Hi Enrico,
>>>>> 
>>>>> I want to pick up on the first question that Ora asked you during today's call and turn that question into a request
>>>>> (not only to you but to the group in general).
>>>>> 
>>>>> I would very much prefer if proposals such as this one are presented not only in terms of an extension of Turtle (or any
>>>>> other concrete syntax for representing RDF graphs) but also in terms of some structure or model that is defined using
>>>>> mathematical concepts (e.g., sets, tuples, functions) and that expressions made in the concrete syntax can be mapped to.
>>>>> I mean, the notion of an RDF graph [1] is such a structure, and so is the notion of an RDF-star graph [2]. I would like
>>>>> to see definitions of such types of notions to be the basis of any proposal. The reason being that the definitions of a
>>>>> model-theoretic semantics and of a query evaluation semantics would build on such notions (and not on expressions made
>>>>> in the concrete syntax).
>>>>> 
>>>>> So, in this sense, what kind of a thing is it that you propose to write in the following form?
>>>>> 
>>>>> |<< :john :teaches :cs101 >>| :recorded "2021-07-07"^^xsd:date .
>>>>> 
>>>>> Similarly, what kind of thing would be written using the following form?
>>>>> 
>>>>> << |:john| |:teaches| |:cs101| >> :recorded "2021-07-07"^^xsd:date .
>>>>> 
>>>>> 
>>>>> Olaf
>>>>> 
>>>>> [1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Frdf11-concepts%2F%23dfn-rdf-graph&data=05%7C01%7Cfranconi%40inf.unibz.it%7Ccb27093faf804a68836d08db1b7ad0c8%7C9251326703e3401a80d4c58ed6674e3b%7C0%7C0%7C638133986518402021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6y47Df2e6Wz3xmb2eNQWbXCC32VPcyQpfmEAInNUs70%3D&reserved=0
>>>>> [2] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Frdf-star%2Fcg-spec%2F%23dfn-graph&data=05%7C01%7Cfranconi%40inf.unibz.it%7Ccb27093faf804a68836d08db1b7ad0c8%7C9251326703e3401a80d4c58ed6674e3b%7C0%7C0%7C638133986518558077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KxUl%2F0CLbYQxrKRapgY%2FWpM6K8hJGME24p1XGMm8jBM%3D&reserved=0
>>>>> 
>>>>> 
>>>>> On tor, 2023-03-02 at 17:59 +0000, Franconi Enrico wrote:
>>>>>> Semantic predication example:
>>>>>> 
>>>>>> << :john :teaches :cs101 >> rdf:type :teaching ;
>>>>>>                           dct:Location dbr:Stanford_University ;
>>>>>>                           dct:PeriodOfTime :1st-term-2022 .
>>>>>> :john :teaches :cs101.
>>>>>> 
>>>>>> Syntactic predication example:
>>>>>> 
>>>>>> |<< :john :teaches :cs101 >>| rdf:type unstar:triple ;
>>>>>>                             :recorded "2021-07-07"^^xsd:date .
>>>>>> 
>>>>>> or
>>>>>> 
>>>>>> << |:john| |:teaches| |:cs101| >> rdf:type unstar:triple ;
>>>>>>                                 :recorded "2021-07-07"^^xsd:date .
>>>>>> 
>>>>>> Modal/epistemic predication example:
>>>>>> 
>>>>>> << :john :teaches :cs101 >> rdf:type unstar:statement;
>>>>>>                           :accordingTo :employee22 .
>

Received on Wednesday, 8 March 2023 20:00:40 UTC