- From: Fabio Vitali <fabio.vitali@unibo.it>
- Date: Wed, 5 Jan 2022 18:42:56 +0000
- To: "Patrick J. Hayes" <phayes@ihmc.org>
- CC: Ted Thibodeau Jr <tthibodeau@openlinksw.com>, "public-rdf-star@w3.org" <public-rdf-star@w3.org>
Dear Pat,
first things first:
> On 4 Jan 2022, at 08:46, Patrick J. Hayes <phayes@ihmc.org> wrote:
> I had vowed to drop out of this discussion,
> let me just point out some of the problems it introduces, then I will go back to quiet retirement.
> OK, last from me on this topic. Y'all go ahead and I will return to retirement :-)
Please don't. I mean, by all means enjoy your retirement, but please find some more time to discuss with us/me. Slowly, even: I can live with that and actually appreciate it, considering that Christmas break is finished and from next week I am back to my usual frenzy, but still, I am enjoying immensely these discussions, and I find your wisdom and competence illuminating and precious. Please reconsider!
>> What I am trying to convey is that we need two types of named graphs, plain containers of asserted triples and containers of non-asserted triples, easy to tell apart and use in different ways.
>
> Sorry, but I can't resist the temptation. See slides starting at 20 in https://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk.
I like it, and like also the idea that we should start nesting named graphs (or this is how I interpret slides 27- ). How I wish we could allow these principles...
Anyway, back to the topic:
> I had vowed to drop out of this discussion, but now I understand what you are actually saying (sorry it took so long), I feel I need to respond to it. I see that your interpretation of RDF-star is what we might call completely opaque. The 'inner' triple is quoted, treated simply as a piece of syntax. The semantics – the meaning – of the annotation triple bears no relation to any meaning that the inner triple might have (when treated as RDF): it is a purely syntactic payload. The annotation – outer – triples have an uninterpreted triple as their subject.
I am not sure I understand what you are saying. If you are referring to referential opacity that is absolutely not true. If there is another issue regarding opacity that I am not aware of, that might be.
> (BTW, an aside. The first RDF WG could have defined the meaning of RDF reification in this kind of way, ie as quotation. But we decided it would be useless, and in any case would not carry what seemed to be the intent of reification (which had been defined by an earlier group and we were chartered to not alter). Which is why reification is not opaque.)
I do not care very much for reification. I care for being able to express triples without asserting them. If RDF-star obtains this through reification, I'll use reification. But reification is not necessary per se for what I need. The solution I have, using conjectures, does not use reification and works fine.
>> The triple :RichardBurton :marriedTo :LizTaylor was never present in the RDF dataset. It is nowhere to be seen. The only triples that WERE asserted, i.e., provided with a truth value, are:
>>
>> << :RichardBurton :marriedTo :LizTaylor >> :startDate "1963"^^xsd:Year;
>> << :RichardBurton :marriedTo :LizTaylor >> :endDate "1974"^^xsd:Year;
>>
>> I asserted them, and I expect them to be understood as "simply true for me". I am not breaking any RDF semantics so far.
>
> Indeed, you are not. But you are also not saying anything about Richard Burton, Liz Taylor, or the relation marriedTo. So what does startDate mean here? The triples seem to say that these dates are the start and end dates of a triple, but what does THAT mean? Why would a triple have a date?
I might agree that :startDate and :endDate are not the clearest names I could devise, and I'll be happy to replace with something else. How about :assertableSince and :assertableUntil?
A quoted triple is a blank node used as subject for exactly six asserted triples, and as the object/subject within whatever triples you used it as quoted.
Consider something we agree is proper and approvable:
<< :RichardBurton :marriedTo :LizTaylor >> :accordingTo :wikipedia.
If I am not incorrect, this triple is expanded according to 6.1 of the RDF-star proposal into:
_:b unstar:subject :RichardBurton;
unstar:predicate :marriedTo;
unstar:object :LizTaylor;
unstar:subjectLexical "<http://www.example.com/RichardBurton>"; // or something like this
unstar:predicateLexical "<http://www.example.com/marriedTo>" ;
unstar:objectLexical "<http://www.example.com/LizTaylor>" ;
:accordingTo :wikipedia ;
In this dataset, the triple :RichardBurton :marriedTo :LizTaylor does NOT appear anywhere, and therefore it is not asserted. No data about :RichardBurton is present anywhere. In particular, the blank node _:b is the subject of all the unstar: predicates PLUS of the additional :accordingTo predicate. Nobody is asserting ANYTHING about :RichardBurton, there are no triples with :RichardBurton asserted anywhere, the amount of knowledge about :RichardBurton is not increased.
Someone MIGHT want to assert the inner triple, for instance if they decide that :wikipedia is correct, and therefore employ a SPARQL Update query that asserts all quoted triples. Yet, in general, wikipedia might not be right and the quoted triple might not be true and therefore the inner triple might remain unasserted indefinitely.
For instance, the following triple is totally similar to the previous one, and has exactly the same truth value as the previous one:
<< :FabioVitali :marriedTo :MargotRobbie >> :accordingTo _:aDreamIMadeYesterday. [*]
Yet, not only in the "real" universe the inner triple is not simply true, it is actually (sadly) simply false. But in our dataset it is exactly identical to the RichardBurton quoted triple, namely, it is unasserted. The outer triple is simply true.
Importantly, there is no need to assert the inner triple in order to work with it: for instance, I can search for all people that dreamt of marrying Margot Robbie without using Marriage entities at all, nor even ImaginaryMarriage entities. The approach works, it is correct, it does not assert false things, it does not assert uncertain things, and it clearly distinguishes simply true statements from expressed but non-asserted statements.
Thus, since quoting a triple makes it unasserted, we can work with unjustified, conjectural, hypothetic and/or patently absurd triples simply by quoting them and assigning them some provenance.
[*] If you insist:
_:aDreamIMadeYesterday a :Dream;
:dreamtBy :FabioVitali ;
:dreamtWhen "2022-01-03"^^xsd:dateTime .
What about temporal constraints? Let's try this:
<< :RichardBurton :marriedTo :LizTaylor >>
:assertableSince "1962"^^xsd:Year;
:assertableUntil "1974"^^xsd:Year.
This triple is expanded according to 6.1 of the RDF-star proposal into:
_:b unstar:subject :RichardBurton;
unstar:predicate :marriedTo;
unstar:object :LizTaylor;
unstar:subjectLexical "<http://www.example.com/RichardBurton>"; // or something like this
unstar:predicateLexical "<http://www.example.com/marriedTo>" ;
unstar:objectLexical "<http://www.example.com/LizTaylor>" ;
:assertableSince "1962"^^xsd:Year;
:assertableUntil "1974"^^xsd:Year.
In this dataset, the triple :RichardBurton :marriedTo :LizTaylor does NOT appear anywhere, and therefore it is not asserted. No data about :RichardBurton is present anywhere. In particular, the blank node _:b is the subject of all the unstar: predicates PLUS of the additional :assertableSince and :assertableUntil predicates. Nobody is asserting ANYTHING about :RichardBurton, there are no triples with :RichardBurton asserted anywhere, the amount of knowledge about :RichardBurton is not increased.
Someone MIGHT want to assert the inner triple, for instance if they decide that their universe is somewhere within the temporal interval [1962-1974], and therefore employ a SPARQL Update query that asserts this quoted triple. Yet, in general, we are not in that temporal interval and the inner triple is not true in an absolute way and therefore the quoted triple should remain unasserted indefinitely.
There is no need to assert the inner triple in order to work with it: for instance, I can search for all people that married :RichardBurton without using Marriage and Divorces entities at all. The approach works, is correct, does not assert false things, does not assert uncertain things, and clearly distinguishes simply true statements from expressed but non-asserted statements.
Therefore, I don't see the problem you see.
>> These triples are not about a Marriage entity, but about the quoted triple << :RichardBurton :marriedTo :LizTaylor >> .
>
> OK, they are about a triple. Got that. But…
>
>> They represent an extremely simple way to add temporal constraints to knowledge, because they do not annotate the Marriage, but the quoted triple.
>
> …then they DONT add temporal constriants /to knowledge/. They add temporal constriants to syntax, to triples (whatever that means). Those annotated triples are no longer data when they are merely quoted: they have been stripped of content.
They add temporal constraints to a triple about a blank node that expresses an unasserted statement. This is not adding to syntax. This is adding to knowledge, in exactly the way that specifying _:b :accordingTo :wikipedia is adding to knowledge (namely, that :wikipedia believes that _:b is assertable).
>> We are just exploring what we can do with non-asserted triples, but talking and constraining quoted triples is VERY interesting from my point of view, because it allows us to discuss about facts that are locally true, or temporally constrained, or conjectural, or hypothetical, or even plainly and laughably false, WITHOUT asserting them and without breaking the usual RDF semantics.
>
> Sure, I have no problems with most of this, as long as we are talking strictly about the triples. But some of this – notably, "temporally constrianed" – is not about the triples, but (in spite of your protestations to the contrary) about what the triples MEAN. And that does break the RDF semantics.
I do not understand what YOU mean when you wonder "what the triples MEAN". To me,
<< :RichardBurton :marriedTo :LizTaylor >>
:assertableSince "1962"^^xsd:Year;
:assertableUntil "1974"^^xsd:Year.
means EXACTLY this, nothing more, nothing less:
_:b unstar:subject :RichardBurton;
unstar:predicate :marriedTo;
unstar:object :LizTaylor;
unstar:subjectLexical "<http://www.example.com/RichardBurton>"; // or something like this
unstar:predicateLexical "<http://www.example.com/marriedTo>" ;
unstar:objectLexical "<http://www.example.com/LizTaylor>" ;
:assertableSince "1962"^^xsd:Year;
:assertableUntil "1974"^^xsd:Year.
I do not think that this breaks the RDF semantics.
>> Any better? I am saying that 1963 is the safest early date where we can expect the quoted triple << :RichardBurton :marriedTo :LizTaylor >> to be assertable.
>
> AssertABLE but not assertED. This is a very delicate distinction to place so much reliance on. What does 'assertable' mean? As a matter of fact, it wasn't assertible in 1963 because RDF hadn't been invented in 1963. Seriously, you have to say what this locution "assertable in X" means. No matter how much you wriggle, I will claim, and I bet 99% readers of that RDFstar will agree, that you are talking about when the inner triple was TRUE. And then you run right into the fact that the RDF semantics doesn't provide for a tensed truth-at-one-time-but maybe-not-another.
Now, this is IMPORTANT. As a matter of fact, it is not possible to express in RDF "when the inner triple was TRUE". This is because there is no "when" with triples in RDF: they are simply true with no temporal constraints. So, no, I am not "talking about when the inner triple was TRUE". I am talking about the next best thing: can I express something that is absolutely true, no "when" in it, and yet allows me to do reasoning, make inferences, ask queries, etc. about time-constrained facts?
We can do this
1) by inventing as many fictional entities as there are temporally-constrained relations, such as Marriages and Divorces, etc. but, then, entia non sunt multiplicanda sine necessitate, and in any case this would imply totally revolutionising the existing non-time-aware datasets, which is pretty invasive in many situations.
OR ELSE, we can do this
2) by assigning temporal constraints to the statements that express the fact, making them NON ASSERTED, and subjecting their assertion to external causes (e.g. some temporal interval). We do not multiply entities, we express something that is simply true, and we can still make inferences and queries on these statements without ever feeling the need to assert them. Win-win.
>> I am not changing its truthvalue by adding meta-descriptions.
>>
>> I am not claiming that it never had a truthvalue until the metadata was added.
>
> So what would it mean to publish that inner triple named, as it were, without any annotations? (Because people will do this, whether you like it or not.) Would it mean that the triple is true now? That violates the RDF semantics, which has no notion of 'now'. Or does it mean there EXISTS a time (unspecified) when it is true? OK, make that existential explicit in RDF, it is a bnode. Now relate that bnode to the other things mentioned in the triple... I am sure you can see where this is going to end up.
Asserting a conditionally-constrained quoted triple creates a NEW dataset whose author decides that the condition has been fulfilled, and signals this by adding one more plain triple identical to the quoted triple, and that is now asserted. If the author is right, we have a dataset representing facts. Otherwise, we do not.
But this is not the point: ASSERTING quoted triple is optional, and not really necessary at all. In general, we should decide to use conditionally-constrained quoted triples EXACTLY BECAUSE we know that these triples are not true per se, and therefore we should never assert them. Yet we can reason with them, make inferences on them, and query them exactly as before. But they are not asserted.
>> I am simply saying that through RDF* we can discuss about quoted triples without ever caring about their truthvalue, whether they are simply true, or temporally bound, or hypothetical, or absurd. Their truthvalue is NOT RELEVANT ANYMORE, and we still are not breaking the usual RDF semantics.
>
> This would be fine if it were true, but I simply don't believe it, and its not consistent with your claim that RDFstar content is 'data'. Does
>
> << :RichardBurton :marriedTo :LizTaylor >> :startDate "1963"^^xsd:Year;
>
> say anything about Elizabeth Taylor, or not? If not, it is not data in any meaningful sense. If yes, then this is not simply quotation of a triple.
No. As the expansion I showed you before clearly implies, this triple says NOTHING simply true about neither :RichardBurton nor :LizTaylor. And you are right: this is not data, this is metadata.
But then, everything we say is metadata: "universals are verbal constructs and [...] they do not inhere in objects or pre-exist them. Therefore, universals are something which are peculiar to human cognition and language." [1] Or, put in another way: "Through a window we view chaos, and relate it to the points on our grid, and thereby understand it. The order is in the grid. That is the Aneristic Principle."
[1] https://en.wikipedia.org/wiki/Problem_of_universals#Medieval_nominalism
[2] https://www.cs.cmu.edu/~tilt/principia/body.html#mu
>> You say: "There is no way to directly express such a difference of opinion in any single RDF graph.".
>>
>> Yes, there is! There is NOW (using RDF-star, I mean).
>>
>> That's my whole reason for using RDF-star (and my proposal, conjectures): to express differences of opinion. This is what makes them valuable! Thus,
>>
>> <<
>> << :monaLisa dc:creator :leonardo >>
>> :startDate "1506"^^xsd:Year
>>>> :accordingTo :louvre.
>>
>> <<
>> << :monaLisa dc:creator :leonardo >>
>> :startDate "1513"^^xsd:Year
>>>> :accordingTo :vezzosi.
>>
>> expresses two points of view that are incompatible with each other. Yet the resulting dataset is not inconsistent, not wrong, and fully within the accepted RDF semantics. That is what makes rdf-star precious.
>
Argh argh argh. The mailer interprets a >> at the beginning of a line as a quotation symbol, damn. No wonder you did not understand my message. Ouch. How can I do?
<<
<< :monaLisa dc:creator :leonardo >>
:startDate "1506"^^xsd:Year >> :accordingTo :louvre.
<<
<< :monaLisa dc:creator :leonardo >>
:startDate "1513"^^xsd:Year >> :accordingTo :vezzosi.
Not nicely formatted, but hopefully this time the characters will not be mangled. Cross my finger.
> As I undertand this – and apologies if I have this wrong – there are two RDFstar triples in each assertion here, each having the (quoted) triple << :monaLisa dc:creator :leonardo >> as subject. But then the final triple in each pair seems to be attributing this triple to two different sources, not the other annotation triple (which refers to a date). Which seems wrong.
>
> (Or should I read this as a three-deep nesting of triples, where the startDate triples have that as subject, and are then quoted again and are then the subject of the next triple, so that the quotations are nested inside one another? That makes more sense, but nested quotation amplifies my concerns about quoted syntax not being real data.)
Yes, yes, yes, the right one is the second interpretation: these are doubly nested quoted triples: according to :louvre, the earliest date in which you could assert that :monalisa was created by :leonardo is 1506, while according to :vezzosi it is 1513. Sorry for the misunderstanding.
>>
>> This is exactly what makes this triple interesting: it doesn't say anything about Mona Lisa, yet I can use it (indirectly) to represent statements detailing information about Mona Lisa, statements that are time-dependent, contradictory, incomplete, competing with each other, or plainly bonkers, and all of this while remaining fully within the plain old RDF semantics.
>
> Well actually I don't think you can. If it doesn't mention the Mona LIsa, it doesn't (can't) be understood to be saying anything about it (her?). You claim to be just using opaque quotation, but you are interpreting it as though it was transparent. Not to be ad hominem, but this is a semantic shell game.
I do not understand the problem: does
<< :RichardBurton :marriedTo :LizTaylor >> :accordingTo :wikipedia.
say anything about :RichardBurton? That's exactly the same situation, only the condition for assertedness is a temporal interval rather a provenance.
>> You are still trying to make the temporal constraint refer to the fact being expressed by the quoted triple, or to the time in which the triple was stated. Neither is true. It is a temporal constraint about the assertability of the triple.
>>
>> In practice you are never expected to assert it, since a temporally-constrained triple is not true in absolute. Yet the temporal constraint about the quoted triples allow us to make (indirect) assumptions about the temporal constraints of the inner fact
>
> HOW? This exposes the shell game clearly. The 'temporal constraint' is, you claim, on the triple, which is not being asserted and whose content is irrelevant, just a piece of syntax. Yet this temporal constraint now appears attached not to a triple, but to an "inner FACT", (my emphasis). Where did that inner fact come from? I guess somebody INTERPRETED the triple to get to the fact. What aspect of the RDFstar semantics justified that move? Perhaps that quotation wan't really a quotation, after all? (And this gets even less plausible if quotations are nested, BTW.)
No no no no.
I mean, yes, this IS a shell game, you are right, because we are attaching constraints (temporal or whatnot) to rdf-star quoted triples that are not asserted, and maybe nest these quoted triples inside other quoted triples and so on, hiding the original triple inside an increasing layering of conditions.
But, at the same time, whether or not these quoted triples say something true about the inner triple is not given, not required, not necessary. For instance,
<< :FabioVitali :marriedTo :MargotRobbie >> :accordingTo _:aDreamIMadeYesterday.
This triple IS asserted, IS simply true, IS undeniable, but the inner triple is NOT TRUE, not even under some very strict conditions. It says nothing about :FabioVitali, it says nothing about :MargotRobbie.
This implies that, the condition to be satisfiable do not constitute a requirement for a correct and valid conditionally-constrained quoted triple, ever.
As in the example I was making with Thomas, the triple
<< :Hitler :not :AllBad >> :accordingTo :noone.
is valid and correct and simply true, yet the inner triple is not and will never be asserted.
>> in order to provide other and more esoteric conditions. They only matter as conditions of the query necessary to retrieve the quoted triple:
>
> Not ONLY for querying. They will also be expected to support other inferences and be used in conjunction with other data. What can you infer from a nested-quotation triple like the marriage example together with
>
> :LizTaylor owl:sameAs https://www.wikidata.org/wiki/Q34851 .
>
> ? I presume, nothing at all. Which is, to put it mildly, a pity.
I do not see the issue. So, are we back to referential transparency? I do not like it, but here we are:
<< :RichardBurton :marriedTo :LizTaylor >> :accordingTo :wikipedia.
says nothing about :LizTaylor as well, for exactly the same reason.
> How about inferring that if RichardBurton is male then LizTaylor must be female (because they were married before 2015)? Or that RichardBurton's date of birth must be earlier than 1945 because one could not be legally married younger than age 18 in 1963? These are all the kinds of thing that an OWL reasoner should be able to squeeze out of this data plus some general facts and a little bit of historical knowledge about marriage.
Cool. You need to adjust the ontology of the reasoner a little bit to handle temporally constrained constraints.
But you should adjust it anyway, because, as you mention, US marriage law permits same-sex marriages after 2015, and of course after another date even gender is not statically assigned to people as well, so you can only deduce either 1) that since the wedding was before 2015, LizTaylor was female at the moment of the wedding, or that 2) since she she died before 2020, she died with the gender assigned at birth, i.e., female, and this of course only applies to US legislation, which I have no idea if it can be used here, considering that both Rick and Liz were British, and Liz was also a US citizen, but Richard was not, so your ontology needs to take into consideration not only the temporal aspects of the marriage, but also the implications of the citizenships of the participants, of the place where the wedding took place and of the country that registered the wedding, adding more and more complexity and, how can I put it, conditional constraints to an already fairly muddled situation.
In general, legal ontologies are VERY VERY complex, they are time- and jurisdiction- dependent, and do not really work well with monotonic logic and simply true statements. And I think I know what I am talking about.
Received on Wednesday, 5 January 2022 18:43:47 UTC