Re: multisets everywhere

Hi Fabio and Pat

It's a very long discussion, but it's right at the heart of what we're
talking about, and I think we're all talking about the same thing.

If Fabio had mentioned a third relation, like so:

    :assertableSince
    :assertableUntil
    :assertablePlace

Then you might recognize it's just a different way of saying:

    :validFrom
    :validTo
    :validPlace

We're all talking about valid times and places.

<< :Pat :arguingWith :Fabio >>
    :assertableSince 2021
    :assertableUntil 2022

(Symmetric relation :arguingWith)

Is the same as:

<< :Pat :arguingWith :Fabio >>
    :validFrom 2021
    :validTo 2022

Is the same as:

:Pat :arguingWith :Fabio
    :startTime 2021
    :endTime 2022

Is the same as:

:Pat :arguingWith :Fabio 2021 2022

It's all the same is it not? My argument is that instead of obfuscating
valid times and places (Fabio had to come up with three different names for
the relations in an attempt to explain them) we give them their place front
and center, making it a feature instead of a bug.

You could argue that validity could also be determined from provenance
information etc, as Fabio is arguing, but in my view there's an order of
assertion and valid times and places are always first:

It's not:

<< :Pat :arguingWith :Fabio >>
    :validFrom 2021
    :validTo 2022
    :statedBy :MargotRobbie

It's more like:

<<
    << :Pat :arguingWith :Fabio >>
        :validFrom 2021
        :validTo 2022
>>
    :statedBy :MargotRobbie

Which is the same as:

<< :Pat :arguingWith :Fabio 2021 2022 >> :statedBy :MargotRobbie

Regards
Anthony

On Thu, Jan 6, 2022 at 5:14 AM Fabio Vitali <fabio.vitali@unibo.it> wrote:

> 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.
>
>
>