- From: thomas lörtsch <tl@rat.io>
- Date: Tue, 4 Jan 2022 15:24:11 +0100
- To: "Patrick J. Hayes" <phayes@ihmc.org>
- Cc: Fabio Vitali <fabio.vitali@unibo.it>, Ted Thibodeau Jr <tthibodeau@openlinksw.com>, "public-rdf-star@w3.org" <public-rdf-star@w3.org>
> Am 04.01.2022 um 08:46 schrieb Patrick J. Hayes <phayes@ihmc.org>:
>
> 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 will confess that I simply did not believe, until now, that anyone could possibly be advocating this idea; but OK, let me just point out some of the problems it introduces, then I will go back to quiet retirement.
RDF-star quoted triples are per the proposed semantics defined as referentially opaque (modulo some tricks with bnodes). Isn’t this quite similar to the semantics for named graphs that Carroll et al proposed in 2004? Of course quoted triples are also types whereas named graphs per that proposal are occurrences but that doesn’t seem to be a topic in this discussion IIUC.
> First, I note that this has absolutely nothing to do, now, with our earlier talk of n-ary relations and how to encode them in a binary framework (which is where I came in). There are no n-ary relations in this opaque framework, not even implicitly. That entire discussion was irrelevant to a notation with this interpretation.
The RDF-star CG report is not really clear about this. Whenever things get technical its advocates resort to the position that the quoted triple is purely syntactic and anything else is not yet specified - see for example the informal :occurrenceOf property. Whenever the utility of such an instrument and its applicability for expressed needs like more concise reification or property graph style modelling is questioned, the answer is - depending on who is asking - that of course this is possible too, just not yet fully specified, or that it is "a can of worms" better to be stayed away from.
I have to confess that I was so occupied with occurrences that I didn’t see the problem that you point out w.r.t. to the marriage example. The marriage example is indeed about a type - the triple described by the quoted triple <<:Burton :marriedTo :Taylor>>, meaning the same everywhere itis stated - and annotations to it. I think the gist of this specific aspect is an httpRange-14 problem: do we interpret
<<:Burton :marriedTo :Taylor>>
as referring to a triple of that type (albeit modulo co-denotation) or to the syntactic string itself (modulo blank nodes, but that’s another issue). Both interpretations are reasonably well possible and as I said above they are both supported, albeit in different ways, by the CG.(*)
Just as with any other identifier on the semantic web it is quite easy to come up with intuitive examples of how a statement talks either about the document itself or what it documents. It is mostly the properties that disambiguate the referent to the human reader, and applications do the same implicitly for poor machines. That’s why the semantic web is working despite this fundamental ambiguity in identification semantics.
This disambiguation however gets increasingly complex with quoted triples as it will have to take the property inside the quote into account as well: a start and end date on a ex:marriedTo relation makes some sense, not so much on a quoted triple itself (but it might describe when a triple was added/removed from some source). An ex:occursIn property doesn’t make much sense on a marriage relation itself, therefor it probably refers to the syntactic triple (however there might be a vocabulary using some :occursIn property to record where the married couple lived, where the wedding took place etc). When the context is application specific machinistic ongoings like versioning and explainable AI the httpRange-14 problem is not much of an issue - but only then, I assume - as the application context is specifically targeting the triples as syntax, and not much interested in what they mean (actually rather actively trying to ignore their meaning).
By and large one will be excused to think that the quoted triple refers to an actual statement of the same form, just without the enclosing chevrons (and no matter if it actually has been asserted or not) as this assumption is implicit even in versioning and explainable AI use cases that motivate the proposed semantics. There is an assumed connection between the quoted triple and the triple it quotes, despite the fact that the quoted triple is just a syntactic representation of the real thing. Well, I agree that this is muddled and brittle and skewed in several ways - I was never a fan, I’m just the messenger here. But I also think that the httpRange-14 problem is still by and large unsolved and requires a solution on its own and RDF-star is not to be blamed for it. But contrary to some popular believes RDF-star even in its pure, type-centric incarnation falls victim to that problem just like any other identifying something in RDF - thanks for pointing that out!
A side note about what a statement states and what it doesn’t state (unrelated to what I said above, but as the topic came up in this thread recently): the much discussed example
<<:Burton :marriedTo :Taylor>> :start 1963; :end 1974 .
can be read as
"Let’s assume a statement claiming a marriage relation between Burton and Taylor.
That marriage relation starts in 1963 and ends in 1974."
That’s okay (ignoring for a moment the httpRange-14 issue, that start and end dates could also refer to the statement itself). The second sentence adds detail about which the first sentence makes no claim. It is important that properties are defined in a way that they welcome such additional information, not prohibit it. The design principle that no statement is allowed to alter the truth of another one OTOH also requires that no statement is allowed to forbid the addition of further detail by other statements. If we can’t rely on that we can forget about weaving a semantic web from disparate sources.
Best,
Thomas
(*) In case the quoted triple refers only to the type as syntactic string (and it is very important to the proponents of this semantics that it refers to the type, not some occurrence) it might seem that there is very little that can sensibly be said about it, like
<<:Burton :marriedTo :Taylor>> :length 26 . // if I counted correctly
Especially the much touted application in explainable AI or versioning might be considered a mistake as it records occurrences of some (type of) triple. Yet, the following example:
<<:Burton :marriedTo :Taylor>> :occursIn :ETLstep_25 .
describes the occurrence of said type in ETL step 25 just fine.
To record further detail about such, possibly multiple occurrences would however require minting identifiers for them (and we're back at multisets which, as the title of this thread still suggests, are lurking just everywhere ;-)
>> On Jan 3, 2022, at 1:50 PM, Fabio Vitali <fabio.vitali@unibo.it> wrote:
>>
>> Dear Pat:
>>
>>>> I also think that the gist of our disagreements is in expecting that all our triples represent "facts" about "reality" (independently of who asserts them) rather than, say, representing "statements" (asserted by someone) that can be expressed either "absolutely" or "subject to boundary conditions".
>>>
>>> No, wait. We need to agree on terminology.
>>>
>>> Suppose I say to someone, "Felix is hungry." Then I have /uttered/ a sentence with three words in it, a physical token of a syntactic entity. By making that utterance, I have /asserted/ a proposition which we could represent as 'The cat named 'Felix' at ///pure.hung.skips is hungry at time 19:45 PST on 1.1.2022' where the implicit indexicals have all been filled in with objective time/space coordinate references.
>>>
>>> Now, the meaning of the utterance was contextual, ie indexical: it could have had a different meaning if uttered by someone else, somewhere else, at a different time. But the (proposition expressed by) the second sentence is not contextual in this way. Its truth does not depend on who asserts it, or where or when it is asserted. It is simply true; and if it had not been true, it would have been simply false. And this is a standard and general-purpose way of getting to sentences which have a straightforward relationship to truth. It is used (pwerhpas implicitly) by virtually all data formats, and has been used since bookkeeping was invented probably in the ferrtile crescent. Anyone who stamps a date onto a document before filing it is using this device.
>>>
>>> Propositions are either true or false. By asserting a proposition, I am claiming it to be true. Not, note, true in a context or true at a time, becasuse we have included all that indexical variation into the proposition itself; but just plain true. The "boundary conditionss", by being mentioned explicitly, have become part of the proposition whose truthvalue is being claimed by the assertion.
>>>
>>> Now, this all maps into the semantic web world of RDF, OWL, etc. as follows: the RDF graph is a sentence which is REQUIRED (by the normative semantics) to be true or false, ie to have.a simple truthvalue. Publishing some RDF is asserting it to be true. And all of that is part of the definition of RDF, so if y'all want to use it in any other way, well, it's a free country, but just be aware you are mis-using it.
>>
>> Ok. let's try again dotting all i's and crossing all t's.
>>
>> Entity A publishes an RDF dataset containing several triples of the form (s_i p_i o_i). Each of them is asserted, i.e. assumed to represent a fact from the point of view of A. They are either "simply true" or at least "simply true for A".
>
> A is asserting them, ie claiming them to be true. The claim belongs to A; the truth that is claimed belongs to the triples.
>
>>
>> Now. With rdf-star, a few of these triples may have a form such as either the subject or the object are RDF* quoted triples << s_j p_j o_j >> :
>>
>> << s_j p_j o_j >> p_i o_i .
>>
>> Quoted triples are not asserted, we agree on this, and they are neither "simply true" nor "simply true for A". At the same time, they are not simply false nor simply false for A. Their truth value is unspecified. We do NOT know if (s_j p_j o_j) is true or false.
>
> Just say: they are not being asserted by A (at least not here). The rest of the verbiage is unnecessary and confusing.
>
>> A great deal of effort was created by this community to ensure that the semantics of RDF was not broken even if we added triples that have no truth value, provided we quote them and place them inside a contextualizing triple, which on the contrary IS asserted.
>>
>
> OK, I follow that now. (I would say, though, that if that is all you wanted to do, it isn't very difficult. Just put RDF triples as entities into an RDF interpretation, and require the quoting syntax to have the obvious meaning, ie " 'foodle' " denotes 'foodle'. It is two lines added to the RDF spec, and is indeed a legal RDF semantic extension.)
>
> (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.)
>
>> Thus said:
>>
>>>> I guess I have a fundamentally nominalistic perspective in which the temporal constraints in
>>>>
>>>>> << :RichardBurton :marriedTo :LizTaylor >>
>>>>> :startDate "1963"^^xsd:Year;
>>>>> :endDate "1974"^^xsd:Year;
>>>>
>>>> are NOT about the reality (i.e., the marriage between Rick and Liz), but about the knowledge context that makes the statement actually asserted. They are about what we KNOW (and how we decide to represent it), and not about what IS.
>>>
>>> Well, I can argue against the utility and indeed accuracy of such a view, and will do so briefly below, but more to the point is that RDF requires that an asserted triple is asserted without a context. Put another way, the truth of the RDF triple
>>>
>>> :RichardBurton :marriedTo :LizTaylor .
>>>
>>> in any RDF interpretation does not, and normatively cannot, depend on any assertions made /about/ that triple. So once asserted, it is asserted without any surrounding context or qualification. Which means that your interpretation is inconsistent with the (sorry to repeat) normative semantics of RDF.
>>
>> 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?
>
> …
>
>>
>>> But to return to your 'nominalist' (?) claim. You are saying that (for example)
>>>
>>> :startDate "1963"^^xsd:Year;
>>>
>>> is not actually a statement about the date of Dick & Liz's marriage, but rather is about what "we know".
>>
>> No. I am saying that it provides a temporal condition on the quoted triple << :RichardBurton :marriedTo :LizTaylor >>
>
> But what does THAT mean? How can an RDF triple have a 'temporal condition'? It is hard to see how thas can mean anything other than a condition on its being true.
>
> (This is where the rubber meets the road for a semantic account, by the way, because if you give that idea of "temporal (and presumably other) condition" flesh, you will I predict have to break the clean picture of this being a form of opaque quotation.)(See below.)
>>
>> I am on purpose moving away from describing the reality (or even the reality as the author of the dataset sees it) and start adding conditions on what is said about reality. They may (and usually have) a connection to the reality (or to the reality as me as the author see it), but, again, this is an added bonus, not a requirement.
>
> But when they do, do you want that connection to be semantically significant? Will the meaning of the RDFstar nested triple ever have ANY connection to the meaning of the inner, quoted, triple? If so, this is not just quotation.
>
>>
>>> Really? About what WHO knows? (To speak of knowledge without a knower is nonsensical.) But in any case, surely this is just wrong. It is a piece of information about the date of a marriage, not about knowledge at all. Of course one could say something like that this assertion represents part of what is 'generally known' about the marriage, but still it is the sentence that is generally known, and what the sentence refers to is a marriage date, not a belief about a date.
>>
>> By interpreting :startDate "1963"^^xsd:Year as an attribute of a marriage, you are still trying to force a Marriage entity inside a (quoted) triple where no Marriage entities have been specified.
>
> I think I am only stating the obvious intended meaning of the RDFstar here. Other readers of this thread (if there are any), would you interpret this as making an assertion about the date of a marriage?
>
>>
>> I am not saying that using Marriage entities is wrong in general: I am saying that within the quoted triple << :RichardBurton :marriedTo :LizTaylor >> there is the predicate :marriedTo, not a Marriage entity.
>
> There is neither of them. There is only a URI ':marriedTo', which is a character string. Triples contain syntax, not relations.
>
>> If you want to use a Marriage entity, you have to get rid of the :marriedTo predicate and use a whole bunch of new predicates (:groom, :bride, etc.) and apply them to a newly created entity of type Marriage. You are fundamentally restructuring and revolutionising the ontology adding many new predicates and entities and throwing away some old ones. Probably, conceptually, the best approach (but is HAS limitations), but at the same time this is a fairly invasive procedure, not always possible.
>>
>>>> In other words, the propositions we are considering should not be viewed as absolutely true or false (or, as you say, simply true or false), but are true when a given state of affairs is obtained.
>>>
>>> No, that is not what this says. When Lindström says "make some proposition about the actual world true" he is saying the proposition is ABOUT the state of affairs (which is a real aspect of the actual world), and it IS true – simply true – just when the world does indeed contain (or maybe /exemplify/ or some such locution: philosophers vary here) that state of affairs. Saying that a proposition is simply true does not imply that the world it describes must be simple. So for example, the proposition that Liz and Richard were married from 1963 to 1974 is true – simply true – because the state of affairs it describes is actual, in the actual world. (If it were "true of" a state of affairs, ie if it needed something extra to make it have a simple truth value, then it would be a predicate, not a proposition.)
>>
>> Please. I am not objecting to whether or not "the proposition that Liz and Richard were married from 1963 to 1974 is true – simply true". Of course, I accept that it is true.
>
> OK, though you did SEEM to argue against it fairly strongly. No doubt I misunderstood you.
>
>> But this is NOT what these triples are saying:
>>
>> << :RichardBurton :marriedTo :LizTaylor >> :startDate "1963"^^xsd:Year;
>> << :RichardBurton :marriedTo :LizTaylor >> :endDate "1974"^^xsd:Year;
>>
>> 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.
>
>>
>>>> Facts about the reality are either (simply) true or (simply) false. On the contrary, conditions about a quoted triple allow us to either ASSERT or NOT ASSERT the triple itself.
>>>
>>> You assert it by publishing it as RDF data. And you 'not assert' it by not publishing it. That is wired into the semantics of RDF.
>>
>> One of the most interesting contribution of RDF* is the ability of publishing triples without asserting them, as "quoted triples", and without breaking the usual RDF semantics.
>>
>> 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.
>
>>
>>>> The quoted triple is neither true nor false, it is provided for contemplation, so to speak, and becomes asserted under some conditions.
>>>
>>> No. We can make assertions about this notorious marriage now, in 2022. We do not (cannot) travel back in time to 1963 in order to make assertions about what happened then. So these dates are not the dates of assertions. (Did you read what I wrote earlier about valid time vs. transaction time?)
>>
>> Now you are assuming that :startDate "1963"^^xsd:Year is the date of the assertion. It is not. I guess you are misreading the name of the :startDate predicate, so I'll use another one.
>>
>> << :RichardBurton :marriedTo :LizTaylor >> :atLeastSince "1963"^^xsd:Year;
>> << :RichardBurton :marriedTo :LizTaylor >> :atMostUpTo "1974"^^xsd:Year;
>>
>> 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.
>
>> Note that I am NOT asserting it, just providing temporal boundary conditions for its assertability. Indeed, the triple :RichardBurton :marriedTo :LizTaylor is NOT true
>
> You mean, not true NOW, I presume. But RDF has no notion of "now". It is not a tensed language.
>
>> , and therefore I do not feel like asserting it.
>>
>> In fact, and this is what makes RDF* interesting, we can work with temporal conditions around quoted triples without feeling any pressure to assert the triples and without breaking the semantics of RDF.
>>
>>>> These are the conditions that obtain the corresponding state of affairs. Under this conceptual frame, the idea of a true triple is foreign and frankly irrelevant: they are are not true or false (this pertains to reality, or possibly to knowledge), but asserted or non-asserted (this pertains to knowledge representation).
>>>
>>> Well (1) this conceptual frame is incompatible with RDF, but also (2) as stated, it is incoherent, or at best muddled. You should try making it formal, and you will soon discover the problems. You will need some variation on the semantics of context logic, by the way.
>>
>> No no. I am saying, loudly and clearly, that I am NOT making anything incompatible with RDF, and that I am using the plain and old RDF semantics, and that if you see contradictions is only because you keep on seeing (made up) entities that are not there in the first place, such as Marriages, and assertions that are not there in the first place, such as :RichardBurton :marriedTo :LizTaylor.
>>
>>
>>
>>>
>>>> Why is this interesting?
>>>>
>>>> 1) because they do not require you to first adopt new entities such as states or events. You can keep on using simple triples representing trivial binary relationships.
>>>>
>>>>> I do not regard events as PSEUDO entities, myself. In fact, the world is pretty much comprised of events, in a suitably broad sense.
>>>>
>>>> Yes, you are probably right. Still, not everybody is using events, not everybody has used events in existing datasets. Should we replace all simple binary relationships with TSD n-ary relationships based on events? More correct, probably. But...
>>>>
>>>> On the other hand, quoting an existing triple is always possible, regardless of the type of conceptual representation that was adopted.
>>>
>>> But changing its truthvalue by adding meta-descriptions is not possible. And claiming that it never had a truthvalue until the metadata was added is even more peculiar. So this is not just RDF-as-usual you are talking about.
>>
>> 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.
>
>> 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.
>
>>>> Right. Good. There are totally expressive representations of reality. I am fine with that and I trust you that it could be done and it has been done. But around here there are a lot of much simpler knowledge representations that haven't gone that far in the correctness of the underlying ontology. They are not wrong per se, but just a bit too simple for these fine points. Quoting is an approach that allows us to represent TSD representations without rewriting them all.
>>>
>>> But it does not, or at least not without a complete overhaul and rewrite of the RDF semantics, which would likely change the intended meaning of all those simple triples. And has not been done, in any case.
>>
>> No. You would be right if I was trying to consider quoted triples as plain RDF triples, which I am not doing.
>
> ? I thought that was exactly what you were insisting that you were doing. This:
>
> :RichardBurton :marriedTo :LizTaylor
>
> is an RDF triple. Really, it is. It conforms to the RDF syntax rules, so…
>
>
>>
>>>>>>> << :monaLisa dc:creator :leonardo >>
>>>>>>> :startDate "1516"^^xsd:Year.
>>>>>>
>>>>>> The temporal constraint is about the truth of the triple, and not about a creationEvent which I did not use, and is therefore true.
>>>>>>
>>>>> … is it? What does :startDate mean? Suppose we discover that Leonardo actually painted it in 1513. Surely, in that case, this assertion about start date would be /wrong/. But this discovery should be consistent with the facts we currently have (and which your RDF should express).
>>>>
>>>> The quoting triple does not talk about :monaLisa, and does NOT mean that :monaLisa was created in 1516. It talks about the quoted triple, and states this triple is asserted in all states of affairs after 1516. Before that time, the statement is unasserted, not false: before 1516, we have no information about its assertedness. This is correct.
>>>
>>> But that is not how 'startDate' is interpreted in other cases, like the marriage. And I suggest it is a very bad idea to impose this open-ended interpretation as a norm. How are you going to represent that actual date, if this is ever determined?
>>
>> You are right, maybe the choice of ":startDate" can lead humans to misinterpret what is being said, I'll use :atLeastSince from now on.
>>
>>>> 4) because conditions aggregate and do not generate inconsistencies. They may generate unobtainable states of affairs, but not logical inconsistencies. For instance, these quoted triples are all correct:
>>>>
>>>>> << :monaLisa dc:creator :leonardo >>
>>>>> :startDate "1516"^^xsd:Year.
>>>>> << :monaLisa dc:creator :leonardo >>
>>>>> :startDate "1715"^^xsd:Year.
>>>>> << :monaLisa dc:creator :leonardo >>
>>>>> :startDate "2021"^^xsd:Year.
>>>>
>>>> These are all legitimate statements, compatible with each other and do not generate any inconsistency.
>>>
>>> Not in your odd interpretation, no. But nobody else is using that interpretation. it seems to me that they /should/ be mutually inconsistent. This is a bug, not a feature. I dread to think what kind of nonsensical conclusions could be drawn from that last one, eg that Leonardo was 569 years old in 2021.
>>
>> These triple are not about Leonardo or about Mona Lisa, they are about the quoted triple << :monaLisa dc:creator :leonardo >> which (I am asserting) was assertable in 1516, in 1715 and even in 2021.
>
> Is there any time when it would not be assertable? If not, it seems rather vacuous to use a date at all.
>
> OK, your strange ontology of time relations is really a side topic. I think it is barmy, myself, but whatever. Not relevant to the main topic.
>
>> The age of Leonardo is not even hinted at, here.
>
> Well, it is surely being HINTED at.
>
>>
>> To clarify it better, let me try again with the newly named :atLeastSince predicate:
>>
>>>>> << :monaLisa dc:creator :leonardo >>
>>>>> :atLeastSince "1516"^^xsd:Year.
>>>>> << :monaLisa dc:creator :leonardo >>
>>>>> :atLeastSince "1715"^^xsd:Year.
>>>>> << :monaLisa dc:creator :leonardo >>
>>>>> :atLeastSince "2021"^^xsd:Year.
>>
>>
>>
>> These are not assertions about a Creation event for a painting, but assertions about temporal conditions on a (quoted) triple.
>
> And what does THAT mean? Apparently, it implies nothing about the entities mentioned in the triple. And I have no idea what it means to say say that triple has a temporal constraint on it. (Not, of course, on its truth, right?)
>
>> The "at least" bit emphasises that these are minimal temporal requirements, not precise boundaries.
>>
>> Now let's try a simple SPARQL+ query: "please tell me what pictures by Leonardo existed in May 1517" (Leonardo moving to France). I separate them in three sets: those that do not have a :atMostUpTo annotation, those that do not have a :atLeastSince annotation, and those that have both; these sets includes all cases.
>>
>> SELECT DISTINCT ?painting WHERE {
>> {
>> << ?painting dc:creator :leonardo >>
>> :atLeastFrom ?date1 .
>> :atMostUpTo ?date2 .
>> FILTER (
>> ?date1 <= "1517-05-01"^^xsd:dateTime &&
>> ?date2 >= "1517-05-31"^^xsd:dateTime
>> )
>> } UNION {
>> << ?painting dc:creator :leonardo >>
>> :atLeastSince ?date .
>> FILTER (?date >= "1517-05-01"^^xsd:dateTime )
>> } UNION {
>> << ?painting dc:creator :leonardo >>
>> :atMostUpTo ?date .
>> FILTER (?date <= "1517-05-31"^^xsd:dateTime )
>> }
>> }
>>
>> This query works with SPARQL*, it is compatible with the RDF semantics, and, crucially, it returns the right results. Of course I know I am not querying Creation events, but annotations about simple (and apparently irrelevant) triples. Still it does work and it is correct and it is (I believe) much simpler to devise and write than a query using creation and destruction events, most of which we have no data about.
>
> Sure, but this is easy. Pretty much any syntactic pattern which makes a recognizable connection between the items you want will return the results when you query it with a matching pattern. Provided of course that you get the pattern /exactly/ right.
>
>>>> 5) because you can represent in a much simpler way competing and incompatible statements. For instance, as we discussed, Mona Lisa was certainly painted before 1516, but scholars discuss about exactly when: the Louvre Museum believes it was painted in 1506, Alessandro Vezzosi after 1513. If we rely on events, this becomes rather complicated:
>>>>
>>>>> :c1 a :creationEvent;
>>>>> :work :monaLisa;
>>>>> :creator :leonardo;
>>>>> :date "1506"^^xsd:Year;
>>>>> :source :louvre.
>>>>>
>>>>> :c2 a :creationEvent;
>>>>> :work :monaLisa;
>>>>> :creator :leonardo;
>>>>> :date "1513"^^xsd:Year;
>>>>> :source :vezzosi.
>>>>
>>>> Both creationEvents exist and refer to the same entities. Only the date and the source differ. How can we assert a preference? That is not clear to me. How do we state that the painting surely existed in 1516, a notion that is implicit but never specified because there is no creationEvent listed for 1516? That is not clear to me.
>>>
>>> I would prefer to say that there is one event, but two opinions as to its starting date. And to say that, we need a (single) name to the event. There is no way to directly express such a difference of opinion in any single RDF graph, because it is a genuine divergence about the facts, and RDF can only describe one world at a time, so to speak. I would use a construct like an RDF dataset to encode such divergences of opinion, with separate graphs for each source.
>>
>> 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.
>
> 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.)
>
>>>>
>>>> By using RDF* and truth conditions, these assertions becomes easy and explicit.
>>>>
>>>>> << :monaLisa dc:creator :leonardo >>
>>>>> :startDate "1516"^^xsd:Year.
>>>>>
>>>>> <<
>>>>> << :monaLisa dc:creator :leonardo >>
>>>>> :startDate "1506"^^xsd:Year
>>>>>>> :accordingTo :louvre.
>>>>>
>>>>
>>>>> <<
>>>>> << :monaLisa dc:creator :leonardo >>
>>>>> :startDate "1513"^^xsd:Year
>>>>>>> :accordingTo :vezzosi.
>>>>
>>>>
>>>> This represents exactly what we are trying to say, including the safe date of 1516 and the fact that the two hypothesis are contrasting and incompatible.
>>>
>>> But are they? If the 'inner' triples are not being aserted, then this graph doesn't say anything about the mona lisa at all. It does not even mention the mona lisa, in fact. But if they are asserted, then yes, we do have a contradiction, regardless of the :accordingTo annotations.
>>
>> I see no need to assert the inner triples. In fact, asserting them would be an error. They MUST NOT be asserted, exactly because they are not simply true. What we are doing here is not asserting simple facts, it is not querying simple facts. We are asserting and querying quoted triples.
>>
>> The triple that is being quoted is NOT ASSERTED (rightly so, because most probably it is not (simply) true), but the quoted triple belongs to a triple that IS ASSERTED in a totally legitimate way, it is simply true, it has a reasonable interpretation (even though it is not about :monaLisa at all), and is fully compatible with the usual RDF semantics.
>>
>> You say: "this graph doesn't say anything about the mona lisa at all"
>>
>> 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.
>
>>>> 6) because we can easily deal with non-events and non-instantaneous events. A non-event is a definite change in state that is not bound with a specific event. For instance, a politician may be a member of parliament from the event of the election he was voted in, until the non-event of failing to obtain a re-election (thank you to my friend Jörge for mentioning this).
>>>
>>> But losing an election is just as much an event (well, a 'state of affairs') as winning one. Non-events are events.
>>
>> Uhm. Differing sensibilities, I guess. If losing an election is an event, you should register as events also the facts that several hundreds of candidates for every parliament seat lost in the same general election, and not just the incumbent MP.
>
> That events (or anything else) exist does not obligate anyone to mention them. There are trees visible in the background of the Mona LIsa, but we don't have to talk about them.
>
>> Not particularly efficient.
>>
>>>> Similarly, a marriage (in its practical, not legal sense) may not start with a priest or a major and a ceremony and a dinner, but, in these modern times, simply when two people start seeing each other more often that others, then progressively exclude anyone else, then start sleeping at each other places more and more frequently, until they start finding stupid paying two rents for two places when basically they have been living together in the one of them for months now, and therefore they let one of the two contracts expire without renewal. What is then the starting event of this relationship? The first sex? The first night sleeping together? The last box moved from the apartment being abandoned? The expiration of the second rental contract? All of them are lowercase correct starting events, none of them is uppercase CORRECT.
>>>
>>> So, it's a complicated world with many blurry edges to our categories. True, a fundamental issue for any descriptive framework. One can make similar points about the exact edges of many things. Where exactly does Mount Everest start? How many lakes are there in Finland? If I am in a city and I drive out of it, exactly where do I enter the countryside? When exactly does human life begin? In practice, we impose artificial, legal or adminstrative boundaries precisely to resolve these kinds of issue cleanly, to avoid endless disputes. But as I say, this is a general issue, not something special to events.
>>
>> My point, exactly. Boundary events are very nice when they clearly stand out over the others, like births and deaths. Less so when they are blurred with the background noise of normal life.
>>
>>>> For instance, the quoted triple
>>>>
>>>>> << :GustavIII :positionHeld :monarch >>
>>>>> :startDate "1771"^^xsd:Year;
>>>>> :endDate "1792"^^xsd:Year;
>>>>> :for :Sweden;
>>>>> :accordingTo :wikipedia;
>>>>> :confidence "1.0"^^xsd:decimal.
>>>>
>>>> is NOT, as you mention, a "muddle between data and metadata", simply because they are all metadata, and the only data is
>>>>
>>>>> :GustavIII :positionHeld :monarch
>>>>
>>>>
>>>> What these triples mean is that, simply, in order to assert the quoted triple you have to constrain the temporal interval to 1771-1792
>>>
>>> Which temporal interval? The one being described, or the one in which the sentence is asserted? Or do you perhaps mean something like a counterfactual, along the lines of, "If it were a time between 1771 and 1792 now, then it would be true to assert…"?
>>
>> 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.)
>
>>
>>>> , you have to constrain the geographical context
>>>
>>> What is a geographical context? Context of what? Of an utterance, or the truth of a sentence, or the location of something in the world? This is just word-salad until you give it some kind of precise flesh in a semantic theory. RDF does not mention contexts anywhere, though Guha did once propose an RDF extension which does.
>>
>> To clarify, conditions on quoted triples belong to many types. Their actual semantics is not relevant.
>
> Of the conditions? Of course it is relevant.
>
>> The predicates :startFrom and :atLeastSince express temporal conditions over a quoted triple only because we see in them a temporal semantics, not because they HAVE a temporal semantics.
>
> That is meaningless. "See in a temporal semantics" is word-salad.
>
>> Similarly we could easily write:
>>
>> << :GustavIII :positionHeld :monarch >>
>> :for :Sweden;
>> :twas :bryllyg;
>> :mimsy "Borogoves".
>>
>> 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.
>
> 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.
>
>>
>> SELECT DISTINCT ?person WHERE {
>> << ?person :positionHeld :monarch >>
>> :mimsy ?mimsies;
>> FILTER (?mimsies IN ("Toves", "Borogoves", "Mome Raths") )
>> }
>>
>> We need not care to understand that :mimsy means: we do not care whether this predicate is black or white, as long as it catches the quoted triples.
>
> Of course. But this is true of all RDF (RDFS, OWL, etc.) in any format. One can always assert nonsense, as long as it fits the syntax. So?
>
>>
>>>> to :Sweden, you have to trust the source :wikipedia, and you have to accept statements with confidence greater or equal to 1.0. They are not statements about Gustav III, but about the triple :GustavIII :positionHeld :monarch .
>>>
>>> So they are all assertions about a syntactic entity? Not even a proposition? Why then does truth even enter into the discussion?
>>
>> I do not know. What is a quoted triple? A syntactic entity? A proposition? Whatever that is, this is what the conditions are assertions about. I do not want to enter into fine semantic discussions. Whatever quoted triples are, they are non-asserted triples that I can use as subjects and objects of asserted triples, and this is something that I can use to represent constrained or conditional or conjectured statements.
>>
>>> And by the way, in our earlier example, the different sources diverged not on the base triple but on another of the annotations (the date). That is not compatible with what you are claiming here, that all the meta-triples refer to the base triple, ie in that earlier case the triple
>>>
>>> :monaLisa dc:creator :leonardo
>>>
>>> which I assume nobody disputes.
>>>
>>
>> I am not sure I understand this.
>>
>>
>>>> 8) How about repeated occurrences?
>>>>
>>>>> But in any case, as others have noted, this does not allow for repeated or interrupted states of affairs, such as the several marriages of of Dick and Liz, or a judge's status while in recusal.
>>>>
>>>> The reason it does not allow for repeated states of affairs is totally due to a specific syntactical choice of RDF* of identifying a quoted triple rather than an occurrence of the triple. The same problem arises with all approaches that do not allow an explicit identifier to their structures, such as quoted graphs in N3. On the contrary, named graphs are, er... named, and thus their name can be used to differentiate repeated states of affairs. With named graphs, this becomes trivial:
>>>>
>>>>>> GRAPH :m1 { :RichardBurton :marriedTo :LizTaylor }
>>>>>> GRAPH :m2 { :RichardBurton :marriedTo :LizTaylor }
>>>>>> :m1 :startDate "1963"^^xsd:Year;
>>>>>> :endDate "1974"^^xsd:Year;
>>>>>> :accordingTo :wikipedia;
>>>>>> :confidence 1.0.
>>
>>>>>> :m2 :startDate "1974"^^xsd:Year;
>>>>>> :endDate "1975"^^xsd:Year;
>>>>>> :accordingTo :wikipedia;
>>>>>> :confidence 1.0.
>>>>
>>>> :m1 and :m2 may have the same content, but are different graphs and can be identified separately.
>>>
>>> That RDF is completely nonsensical.
>>
>> Yes, because named graphs are not allowed to be expressed but not asserted in rdf-star.
>>
>>> True, but they have the exact same truthvalue in any RDF interpretation, and I would expect that to be the case in any future modifcation or extension to RDF. (If not, how can any valid RDF conclusions be drawn from any named graph?) So no amount of annotating them is going to affect what they actually assert. They might have different provenance, of course, but they cannot be true under different circumstances or true ABOUT different things, because they are not "about" anything: they are simply sentences which have a truthvalue and are claimed to be true when asserted.
>>
>> You are totally right. That is a limit of RDF-star in that it constrains non-assertion to individual triples and not whole graphs. This is EXACTLY why I am trying to convince this group to extend the coverage of rdf-star to include non-asserted named graphs. Once we could do that, an RDF similar to the one above would become acceptable.
>>
>> Let me try again with the following example, and using a simple syntax I just made up. Suppose we have two types of graphs, clearly separated syntactically, one understood as a container of asserted triples and the other understood as a container of non-asserted triples:
>>
>> NON-ASSERTED GRAPH :m1 {{ :RichardBurton :marriedTo :LizTaylor }}
>> NON-ASSERTED GRAPH :m2 {{ :RichardBurton :marriedTo :LizTaylor }}
>> :m1 :atLeastSince "1963"^^xsd:Year;
>> :atMostUpTo "1974"^^xsd:Year;
>> :accordingTo :wikipedia;
>> :confidence 1.0.
>> :m2 :atLeastSince "1974"^^xsd:Year;
>> :atMostUpTo "1975"^^xsd:Year;
>> :accordingTo :wikipedia;
>> :confidence 1.0.
>>
>> The content of the graphs :m1 and :m2 is NOT ASSERTED, just like the content of a quoted triple is NOT ASSERTED. Thus said, each of them is associated to a different set of constraints that clearly allow you to differentiate and to query each individual marriage, just what we were trying to do.
>
> But suppose someone (perhaps by your lights misguided, but following the RDF semantic intuitions) were to inspect this and assert
>
> :m1 owl:sameAs :m2 .
>
> ? After all, they are the same /graph/. You are (mis?)using two different graph tokens to encode two different events (I know you disagree, but I think you actually are doing this) but events and triples are not the same kind of thing and don't have the same identity conditions.
>
>>
>>>> Unfortunately, of course, the semantics of named graphs prevent us to consider the content of the graph as unasserted.
>>>
>>> Named graphs allow this, even if RDF* doesn't. At least, the notion defined in our old paper (which introduced the terminology) does. https://deliverypdf.ssrn.com/delivery.php?ID=348094069068098092123083121126004024054087061054024018026038100122094066068094114118014088008083029062047001096072094067125023064102015014080098075065064102024126001028031070079119115090&EXT=pdf&INDEX=TRUE.
>>> See section 3.1
>>
>> I know and I totally admire this work and I respect what it was able to obtain. Unfortunately, RDF 1.1 leaves the state of assertedness of the content of named graphs as unspecified, so, depending on local rules, they may either be unasserted or simply containers of triples.
>
> True. Worse, the 'name' (the associated URI label in an RDF dataset) need not denote or identify the graph it 'names'. My biggest failure in trying to get the RDF1.1 semantics clear, and a parable of why one should not let users get hold of something before it is fully defined.
>
>>
>> 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.
>
> ---------
>
> OK, last from me on this topic. Y'all go ahead and I will return to retirement :-)
>
>> 2) PREVISION: like it or not, rdf-star quoted triples WILL be used in this way in the near future in many communities where the need to express different, competing, reciprocally inconsistent, and/or temporally constrained statements is particularly pressing.
>>
>
> I am sure you are right, unfortunately.
>
> Pst
>
>> Fabio Vitali Tiger got to hunt, bird got to fly,
>> Dept. of Computer Science Man got to sit and wonder "Why, why, why?'
>> Univ. of Bologna ITALY Tiger got to sleep, bird got to land,
>> phone: +39 051 2094872 Man got to tell himself he understand.
>> e-mail: fabio@cs.unibo.it Kurt Vonnegut (1922-2007), "Cat's cradle"
>> http://vitali.web.cs.unibo.it/
>>
>>
>>
>>
>
Received on Tuesday, 4 January 2022 14:24:42 UTC