- From: Fabio Vitali <fabio.vitali@unibo.it>
- Date: Mon, 3 Jan 2022 21:50:13 +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:
>> 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".
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. 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.
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.
> Now, one might simply dismiss the published semantics of RDF as irrelevant, of course: but this path comes with some snags. FIrst, it means that the meanings of other constructs, such as OWL or SPARQL, have /their/ semantics defined in conformity with RDF, so you are here rejecting the entire semantic underpinnings of the entire web. Second, it means that you can have no confidence in the results of any RDF (or RDFS, OWL etc.) reasoners when used on your deviant RDF. Maybe their RDF-valid inferences will preserve your intended meanings, maybe not. Until you define a semantics for your RDF-manque and relate it to the normative RDF semantics, there is no way to know.
I am plainly and flatly using your usual and well-understood RDF semantics, nothing more, nothing less.
> 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 >>
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.
> 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 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. 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. 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 >> . They represent an extremely simple way to add temporal constraints to knowledge, because they do not annotate the Marriage, but the quoted triple.
>> 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.
>> 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. Note that I am NOT asserting it, just providing temporal boundary conditions for its assertability. Indeed, the triple :RichardBurton :marriedTo :LizTaylor is NOT true, 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.
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.
>> 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.
>>>>> << :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. The age of Leonardo is not even hinted at, here.
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. 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.
>> 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.
>
>>
>> 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.
>> 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. 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 even in presence of incomplete, inconsistent and contradictory information.
This is nice.
>> , 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. 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. 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:
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.
>> 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.
>> 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.
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.
> ————
>
> To sum up. RDF assumes, and requires normatively, a simple, basic, 'vanilla' picture of meanings and truth. RDF graphs, and the triples they contain, are simple sentences asserting that a binary relation holds between two entities, all named by URIs (and bnodes and literals, OK). Publishing a graph is understood to be asserting these sentences, ie to be claiming that they are (simply) true. There is no hidden machinery of contexts or tenses or points of view or any other philosophically sophisticated stuff behind the simplicity of RDF. To say that a triple is true is not to say it is true 'now', or true 'here', or probably true, or claimed to be true by some authority; just that is, in fact, true. To repeat, all of this is built into the normative semantics of RDF (and, by the way, of RDFS and OWL and N3), and cannot be rejected without failing to have RDF conformity. Of course, y'all are free to mis-uase RDF, at the risk of being widely misunderstood, and also free to invent new RDF++; but if you do, please specify the semantics with some precision, to avoid having debates like this one.
I totally agree 100% with what you say. 110%, even.
What I am trying to say is that it is possible NOW to use rdf-star quoted triples to obtain different, competing, reciprocally inconsistent, temporally constrained states of affairs WITHOUT BREAKING THE EXISTING RDF SEMANTICS (assuming that rdf-star does not, in fact, break it).
This is NOT a new RDF, this is not a different RDF, it lies plainly and squarely WITHIN THE CURRENT SEMANTICS of RDF, it uses plainly and squarely existing RDF tools (well... rdf-star tools) including sparql-star engines, rdf-star triplestores, etc.
... BUT ...
... it DOES allow you to say that a (quoted) triple "is true 'now', or true 'here', or probably true, or claimed to be true by some authority". Or, to be more precise, it DOES allow you to say that a (quoted) triple is asserted 'now', or asserted 'here', or probably asserted, or claimed to be asserted by some authority".
---
To sum up. Let me give you a fact, a prevision and an opinion:
1) FACT: like it or not, using rdf-star quoted triples to express different, competing, reciprocally inconsistent, and/or temporally constrained statements is LEGAL now, within the current RDF semantics (or, at least, the current rdf-star semantics). It also does not break anything in existing, traditional RDF datasets. It is also fully compatible with more sophisticated time aware-approaches including n-ary relationships.
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.
3) OPINION: this is actually a good thing.
Ciao
Fabio
--
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 Monday, 3 January 2022 21:50:33 UTC