Re: multisets everywhere

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?

*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/
> >>
> >>
> >>
> >>
> >
>
>
>