Re: multisets everywhere

Yeah no problem, there are so many emails here.

I'll add dates, trying to guess which dates you might mean, but not sure if
I've guessed right:

*Asserted case:*
:Employee38 :jobTitle "Assistant Designer" 2018 2019
    { :desk 8 }
    {|
        :statedBy :Employee22,
        :stated 2022
     |} .

Expands to:

:Employee38 :jobTitle "Assistant Designer" 2018 2019 .
{ :Employee38 :jobTitle "Assistant Designer" 2018 2019 } :desk 8 .
<< :Employee38 :jobTitle "Assistant Designer" 2018 2019
>> :statedBy :Employee22 .
<< :Employee38 :jobTitle "Assistant Designer" 2018 2019 >> :stated 2022 .
<< { :Employee38 :jobTitle "Assistant Designer" 2018 2019 } :desk
8 >> :statedBy :Employee22 .
<< { :Employee38 :jobTitle "Assistant Designer" 2018 2019 } :desk
8 >> :stated 2022 .

*Unasserted case:*
<<
    :Employee38 :jobTitle "Assistant Designer" 2018 2019
        { :desk 8 }
>>
    {|
        :statedBy :Employee22,
        :stated 2022
     |} .

Expands to:

<< :Employee38 :jobTitle "Assistant Designer" 2018 2019
>> :statedBy :Employee22 .
<< :Employee38 :jobTitle "Assistant Designer" 2018 2019 >> :stated 2022 .
<< { :Employee38 :jobTitle "Assistant Designer" 2018 2019 } :desk
8 >> :statedBy :Employee22 .
<< { :Employee38 :jobTitle "Assistant Designer" 2018 2019 } :desk
8 >> :stated 2022 .

Is that what you mean? Thanks for looking this over by the way.

Regards
Anthony

On Thu, Jan 6, 2022 at 12:21 AM thomas lörtsch <tl@rat.io> wrote:

>
>
> > Am 05.01.2022 um 14:45 schrieb Anthony Moretti <
> anthony.moretti@gmail.com>:
> >
> > Actually, just a day ago I sent an example like that, I modified example
> 1 from the CG report to make it a 3-ary relationship. I'll paste it here
> for you:
> >
> > Asserted case:
> > :Employee38 :jobTitle "Assistant Designer"
> >     { :desk 8 }
> >     {| :accordingTo :Employee22 |} .
> >
> > Expands to:
> >
> > :Employee38 :jobTitle "Assistant Designer" .
> > { :Employee38 :jobTitle "Assistant Designer" } :desk 8 .
> > << :Employee38 :jobTitle "Assistant Designer" >> :accordingTo
> :Employee22 .
> > << { :Employee38 :jobTitle "Assistant Designer" } :desk 8 >>
> :accordingTo :Employee22 .
> >
> > Unasserted case:
> > <<
> >     :Employee38 :jobTitle "Assistant Designer"
> >         { :desk 8 }
> > >>
> >     {| :accordingTo :Employee22 |} .
> >
> > Expands to:
> >
> > << :Employee38 :jobTitle "Assistant Designer" >> :accordingTo
> :Employee22 .
> > << { :Employee38 :jobTitle "Assistant Designer" } :desk 8 >>
> :accordingTo :Employee22 .
> >
> > The different delimiters "{ }" and "{| |}" enable you to leave the first
> section blank and still recognize the second section as metadata rather
> than data, for example:
> >
> > :Employee38 :jobTitle "Assistant Designer"
> >     {| :accordingTo :Employee22 |} .
> >
> > The above is the same as the current annotation syntax in the report
> actually.
> >
> > It seems to work but yeah I could be missing something,
>
> I’m missing the dates in this example so I don’t know how this response
> relates to your last response (to which I replied that I do indeed
> disagree). I also don’t see how it relates to my initial post on this
> thread about multisets so please forgive me if I don’t give all of your
> posts my full attention.
>
> Thomas
>
>
>
> > if you have examples of how it doesn't work please send them and I'll
> take a look. The more critiquing the better IMO.
> >
> > Regards
> > Anthony
> >
> > On Wed, Jan 5, 2022 at 11:03 PM thomas lörtsch <tl@rat.io> wrote:
> >
> >
> > > Am 05.01.2022 um 00:40 schrieb Anthony Moretti <
> anthony.moretti@gmail.com>:
> > >
> > > Hi Thomas
> > >
> > > 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.
> > >
> > > I'd say most of us on this thread agree by now that that statement is
> improperly structured. Optional time and space positions, and other fixes I
> suggested in my two previous messages, seem to solve the problem entirely
> though. I guess you disagree?
> >
> > Yes I do disagree. Just beacuse this example uses dates doesn’t mean
> that dates are the only possible application of statement annotation. Your
> approach doesn’t scale to other dimenions, not even to the also very
> popular example of provenance information.
> >
> > Thomas
> >
> >
> > > Asserted case:
> > > :Burton :marriedTo :Taylor 1964 1974
> > >     {|
> > >         :stated 2022
> > >     |}
> > >
> > > Expands to:
> > >
> > > :Burton :marriedTo :Taylor 1964 1974
> > > << :Burton :marriedTo :Taylor 1964 1974 >> :stated 2022
> > >
> > > Unasserted case:
> > > << :Burton :marriedTo :Taylor 1964 1974 >>
> > >     {|
> > >         :stated 2022
> > >     |}
> > >
> > > Expands to:
> > >
> > > << :Burton :marriedTo :Taylor 1964 1974 >> :stated 2022
> > >
> > > Regards
> > > Anthony
> > >
> > > On Wed, Jan 5, 2022 at 12:55 AM thomas lörtsch <tl@rat.io> wrote:
> > >
> > >
> > > > 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/
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > >
> >
>
>