Re: Three ideas

On 20/01/2022 20:16, Patrick J. Hayes wrote:
(in a discussion about the difference between ':JoeBiden :presidentOf 
:USA' and ':JoeBiden :name "Biden"')
>
> Well – and I am being purely pragmatic here – the former is inherently 
> and widely understood to be time-constrained, to the point where a 
> conversation like "Joe Soap was President" ="When?" is quite natural; 
> whereas name changes are uncommon and when they happen to public 
> figures, rare enough to be notable (c.f. The Artist formerly known as 
> Prince, or Cassius Clay//Muhammed Ali).

And maybe there is a lead here on establishing good practices about when 
to use RDF-star vs. classical N-ary relations in plain RDF...

If a relationship is immediately identified to be time-constrained (or 
context-dependant in other ways), then it is probably best to model it 
as an N-ary relation (or other patterns, such as the one propoed by Pat 
below).

On the other hand, if a relationship was initially thought to be 
"simple" enough to be modeled as a predicate, and turns out to be more 
complex (either because of some exceptional cases, such as people 
changing name), then RDF-star provides a smooth transition from the 
original modelling to a more detailed one.

   pa

>
>> Why is the second one changing a "genuine change to the data" and the 
>> other not? Why are they different? Would you mind showing me the 
>> correct way to describe Biden as president?
>
> There is no "correct way", but my general rule would be, if the 
> assertion clearly has an implicit "now", then it should include an 
> explicit time in it. Things like being President are widely thought of 
> as 'roles', so that the role exists timelessly but the person 
> occupying it changes from time to time. Hence such cliche's as "The 
> king is dead: long live the king." Then one way to write this in RDF 
> would be to have an ontology of roles, so it might look like
>
> bio:JimmyCarter xx:USPresident "1977-1981"^^xsd:TimeInterval .
>
> (where I am assuming that XML schema gets to have a time-interval 
> datatype, so replace this with some other way to trefer to the 
> timeperiod if you prefer) and we also know, from an ontology called 
> XX, things like
>
> xx:USPresident rdf:type xx:TemporallyConstrainedRole .
> rdfs:Domain xx:USPresident xx:PresidentsOfUSA .
> xx:PresidentsOfUSA rdfs:subClassOf xx:USNativeCitizen .
> rdfs:Range xx:USPresident xsd:TImeInterval .
>
> So that PresidentsOfUSA is an RDFS class of current and former US 
> Presidents, connecting the time-linked property to the category of 
> individuals.
>
> Would that do? Like any such convention, this requires of users of 
> SPARQL to know enough about how things are represented to be able to 
> write coherent queries. But that is always the case, however we choose 
> to write things in RDF.
>
>> I think Peter put it well when he said thinking about this stuff 
>> would rot your brain, my brain is definitely rotting right now haha.
>>
>>     It would require a total rewrite of the RDF specs and coming to
>>     clear, universally accepted, answers to a host of thorny questions.
>>
>>
>> That's a good enough answer to me I guess, but would it still be the 
>> case if it was just a "widely recognized timestamping convention" at 
>> the statement level?
>
> Yes. Suppose we just say, add a timestamp and that's all. Presumably 
> some timestamps are more exact that others (seconds versus calendar 
> years, say). So we have one assertion stamped with 2022, another with 
> 1642705241 Unix time. Are they at the same time? Does the first 
> assertion hold at the second time (which is inside 2022) or not? This 
> depends on whether a 'vague' timestamp means 'at some time in the 
> interval' or 'at all times in the interval' or maybe something else, 
> depending on what is being asserted. If we are goung to adopt a 
> convention then we need to answer questions like this, and the answers 
> have to work for all cases because it will then be baked into the 
> formalism itself.
>
> Pat
>
>>
>> Thanks for your time!
>> Anthony
>>
>> On Thu, Jan 20, 2022 at 2:44 PM Patrick J. Hayes <phayes@ihmc.org> wrote:
>>
>>
>>
>>>     On Jan 19, 2022, at 2:59 AM, Anthony Moretti
>>>     <anthony.moretti@gmail.com> wrote:
>>>
>>>     Hi Pat! Thanks for joining the discussion!
>>>
>>>     I honestly don't mind if all of the ideas I've put forward are
>>>     wrong, I'll drop them the second there's a convincing argument
>>>     against them and be happy to have learnt things in the process,
>>>     it just doesn't seem like the case yet. So, let's jump in!
>>>
>>>     That the atomic number of sodium is 11 is simply true. It is not
>>>     true "at a time". To ask when it is true, or to try to give its
>>>     truth some kind of temporal scope or limit, is to commit a
>>>     category error.
>>>
>>>     This was the example we talked about in private, and I'll retype
>>>     what I said for the benefit of anybody who might be reading. In
>>>     short I said: "Was it true ten minutes ago? Yes. Is it true
>>>     now? Yes.
>>
>>     It is just true. It is not true AT a time except in a sense which
>>     is something like "If you were to ask me if this is true at time
>>     T, I would say Yes." And of course that idea, of being assented
>>     to at a time, has a temporal dimension. But that does not imply
>>     that the truth of the assertion is in any way related to time. It
>>     is also true /wherever/ it is asserted. Also at any height above
>>     sea level. Also /however/ it is said. If you whisper "Atomic
>>     number of sodium is 11" softly it is true; and if you shout it
>>     loudly it is true. Does this show that the truth of
>>     the proposition is somehow relative to a range of ways it can be
>>     said out loud?
>>
>>>     Therefore even that relationship has an extent in time."
>>
>>     No, it doesn't show anything of the kind. If you believe that
>>     truth must be truth at a time, then it might show that; but that
>>     obviously begs the question.
>>
>>>
>>>     On the Bette Davis example, maybe you can clarify something for
>>>     me. Do Tarskian truth conditions apply in RDF?
>>
>>     Yes, if I understand your question. LIke most logical semantic
>>     theories, the RDF semantics is based on Tarskian model theory. Is
>>     that what you meant?
>>
>>>     Sincere question because I've assumed that recently, but I don't
>>>     know for sure. '"P" is true if, and only if, P'.
>>
>>     Um…yes, though of course RDF is not remotely expressive enough to
>>     state the Tarski T sentence.
>>
>>>     Doesn't that imply bounds for temporal validity?
>>
>>     No, of course not. Where in that sentence do you see any
>>     reference to time?
>>
>>>
>>>     If I have this triple:
>>>
>>>     :JoeBiden :presidentOf :UnitedStates
>>>
>>>     Isn't that true only for a period of time?
>>
>>     In a tensed language, where assertions are made at times and we
>>     can use 'now' and future and past tenses, yes. In a simple
>>     assertional logic (like RDF, RDFS, OWL, FOL, HOL, …), no. Truth
>>     in such languages is not relativized to times of assertion.
>>
>>     By the way, even a tense logic would not be suitable for
>>     recording data. The unmarked case in a tensed logic assertion, ie
>>     in the 'present tense' without using past or future modalities,
>>     is asserted as being true "now". But of course "now" when the
>>     data is recorded or published will not be 'now' when it is used,
>>     later. So we would still need some way to record and incorporate
>>     the time the assertion is intended to be about, expressed in some
>>     untensed way.
>>
>>>     Are we meant to avoid saying things like that?
>>
>>     I wish people would not (though it is more acceptable if it is
>>     clearly asserted inside some context with a universally
>>     understood date/time marker. See below.)
>>
>>>     What about:
>>>
>>>     :JoeBiden :name "Joe Biden"
>>>
>>>     He could change his name in the future. It's becoming a bit
>>>     unclear to me what I'm allowed to say in RDF or when I'm allowed
>>>     to say them.
>>
>>     First, you are ALLOWED to do whatever you want. The issue is,
>>     will other users be able to understand your meaning wihtout
>>     getting confused? Where "users" include RDF-valid
>>     inference engines which might use your RDF together with RDF
>>     written by others who might be expressing themselves with more
>>     precision.
>>
>>     I wouldn't have any problem with treating name changes as genuine
>>     changes to the data rather than a time=related assertion, by the
>>     way.
>>
>>>     If I'm meant to timestamp my graph, isn't that the same thing as
>>>     saying it has a temporal validity?
>>
>>     Yes, I agree that some widely recognized timestamping convention
>>     would allow one to make assertions like this more safely. But
>>     note that "widely recognized" (avoiding words like 'standard' and
>>     'normative'). And relative to your last point, then we would be
>>     taking the timestamp to be part of the asserted sentence, in some
>>     way. And as I have explained in earlier posts, once the time (and
>>     ony other 'contextual' parameters relevant to truth) is included
>>     into the asserted sentence, that (larger) sentence is simply true.
>>
>>>
>>>         And even in a tensed language, we *can* speak of the future.
>>>         We can even speak of futures that we believe will not exist:
>>>         this happens all the time in planning, for example, where
>>>         a reasoner might decide to not do something because it
>>>         forsees that if it does do it, bad things will happen. So
>>>         the present cannot be a bound. So what is the bound? 
>>
>>>
>>>     Yes, I agree we can speak about the future, I made that point
>>>     earlier in the thread. We can describe future events in the same
>>>     way that we can describe fictional things.But those
>>>     statements won't be true in a Tarskian sense until those futures
>>>     eventuate
>>
>>     No, sorry, this is nonsense, and it has nothing to do with
>>     Tarski. Look, you just contradicted yourself. We "describe"
>>     future events by asserting sentences (or maybe propositions)
>>     about them. If these sentences are not (claimed to be) true, then
>>     we have not made any assertions at all. To describe IS to claim
>>     truth.
>>
>>>     , hence the present being an upper bound.
>>>
>>>         I wonder, do you realize that you are not just arguing with
>>>         RDF here, but with close to 1.5 centuries of formal
>>>         philosophy of logic? Ever since Prior first described tense
>>>         as a modality, tensed modal logics have been a clear
>>>         subfield, but AFAIK nobody has concluded that all of logic
>>>         must be tensed (still less spatially situated), or that the
>>>         notion of truth is itself inherently temporal in nature.
>>
>>>
>>>     I just did a quick google of these things
>>
>>     Oh, come on. You did a "quick google" of over a century of
>>     literature in a field of precise philosophy, much of it using
>>     fairly heavy mathematics, and that justifies a (false) conclusion?
>>
>>     The Stanford Encyclopedia of Philosophy (widely taken as
>>     authoritative) has a main article on 'Truth', which says
>>      ".. for this discussion, sentences are fully
>>     interpreted sentences, having meanings. We will also assume that
>>     the sentences in question do not change their content across
>>     occasions of use, i.e., that they display no context-dependence.
>>     We are taking sentences to be what Quine (1960) calls ‘eternal
>>     sentences’."
>>     The article does not even mention any notion of truth relativized
>>     to times or other contexts or parameters.
>>
>>>     and it looks like an ongoing debate between tensed and tenseless
>>>     theories of time,
>>
>>>     and some people arguing that both are valid.
>>
>>     Valid? Of course tensed languages exist and are coherent. Modal
>>     tense logics have a very elegant semantics, courtesy of Kripke,
>>     and have been very thoroughly studied. My point is not that they
>>     are somehow 'invalid", but that RDF is not one of them. And I
>>     assure you that if it were, its semantics would look very
>>     different than it now does.
>>
>>>     If that's so, does it hurt to add optional time and space
>>>     positions like I'm suggesting?
>>
>>     It would require a total rewrite of the RDF specs and coming to
>>     clear, universally accepted, answers to a host of thorny
>>     questions. For a start, what structure do we presume time to
>>     have? (A line? Branching futures, so a tree? Or a forest?)
>>     DIfferent answers yield different notions of validity for tensed
>>     sentences.
>>
>>     But in any case, adding tenses doesn't help, as noted earlier.
>>
>>     Pat
>>
>>>     It feels intuitive
>>>     , and I see it as a solution to a lot of modeling problems.
>>>
>>>     Regards
>>>     Anthony
>>>
>>>
>>>     On Wed, Jan 19, 2022 at 5:17 PM Patrick J. Hayes
>>>     <phayes@ihmc.org> wrote:
>>>
>>>
>>>>     On Jan 17, 2022, at 8:02 PM, Anthony Moretti
>>>>     <anthony.moretti@gmail.com> wrote:
>>>>
>>>>     If anybody isn't following Pierre-Antoine and me, I'll try to
>>>>     give a summary of what I think the problem might be, and I'll
>>>>     follow it with an example. There's an example in my last email
>>>>     too, Obama's first term as president.
>>>>
>>>>     In typical modeling, events have an ID and you can use that ID
>>>>     to find statements about the start and end time of the event.
>>>>     If you have reoccurring events, like the celebrity
>>>>     marriage example, there's no problem because each event is
>>>>     uniquely identified.
>>>>
>>>>     In RDF-Star, people are creating events by annotating triples
>>>>     with start and end times, and often there are accompanying
>>>>     annotations. If there's a reoccurring event, or if the
>>>>     annotations are only about a specific part of an event, when
>>>>     you do the expansions you no longer know which event the
>>>>     accompanying annotations are about because there are no event
>>>>     IDs and the core triples being used as the subject of those
>>>>     annotations are identical.
>>>>
>>>>     In my view the problem isn't with RDF-Star it's with RDF. I
>>>>     think the basic unit of description, the triple, is missing
>>>>     components. Every triple describes a relationship and every
>>>>     relationship has an extent in time.
>>>
>>>     Wrong.
>>>
>>>>     Things can't be in a relationship if they don't exist yet
>>>
>>>     Wrong
>>>
>>>>     , and the future is yet to happen, those two things mean that
>>>>     every relationship is implicitly lower-bounded by the existence
>>>>     of the things being described
>>>
>>>     Wrong
>>>
>>>>     , and implicitly upper-bounded by the present.
>>>
>>>     No, that is all completely mistaken. Relations as such have
>>>     nothing whatever to do with time – unless, of course, they are
>>>     relations between times or other temporal things. And a
>>>     fact represented by an assertion (such as an RDF triple) of a
>>>     relation holding between things need not  be inherently temporal
>>>     in any way. That the atomic number of sodium is 11 is simply
>>>     true. It is not true "at a time". To ask when it is true, or to
>>>     try to give its truth some kind of temporal scope or limit, is
>>>     to commit a category error.
>>>
>>>     This is, or should be, simply obvious for facts about
>>>     mathematics or scientific physical data, but it also true of
>>>     many of the everyday asssertions found in ordinary prose. Take
>>>     for example this, from a Wikipedia biography: "<Bette Davis> had
>>>     her critical breakthrough playing a vulgar waitress in Of Human
>>>     Bondage (1934) although, contentiously, she was not among the
>>>     three nominees for the Academy Award for Best Actress that
>>>     year." That sentences contains several linked assertions which
>>>     are (I presume) true. But they are not true at any particular
>>>     time. That Bette Davis played the part of a vulgar waitress in
>>>     the move 'Of Human Bondage' in 1934 is TRUE. It is not true-now
>>>     or true-after-1934 or -after-(5 April 1908). It is a simple fact.
>>>
>>>     Now, you might object that it wasn't true in, say, 1921 (because
>>>     it hadn't happened yet) or 1847 (because Bette Davis didn't
>>>     exist then), but all such claims commit the same mistake, of
>>>     taking truth to be something with a tense. Supose (perhaps at a
>>>     seance) someone in 1847 had spoken this sentence, perhaps in a
>>>     trance, and it had been carefully recorded at the time and then
>>>     a historian in 1953 had found this record, would people say,
>>>     Wow, what an amazing prediction? Or would they say, So what, it
>>>     wasn't true in 1847, so it wasn't a prediction at all? Your rule
>>>     would require the latter.
>>>
>>>     Even if one takes the view (which I think you do) that all truth
>>>     claims are tensed, time-relative, and the apparent timelessness
>>>     of mathematical or scientific facts merely hides an
>>>     implicit universal quantification, so that one should understand
>>>     "the atomic number of sodium is 11" to be shorthand for "at all
>>>     times T, the atomic number of sodium is 11 at time T"; even
>>>     then, that Bette Davis played the part of a vulgar waitress in
>>>     the move 'Of Human Bondage' in 1934, was just as true in 1847 as
>>>     it is now. Of course, nobody knew it was true then, and
>>>     certainly nobody had any kind of epistemic licence to assert it
>>>     back then; but it was true. That sentence is not in any way
>>>     indexical, so its truth does not depend on when it was asserted
>>>     (unlke, say "Bette Davis will appear in a movie 89 years from
>>>     now"), so if it is true when asserted in 1934 or 2021, then it
>>>     is equally true when asserted in 1847 or indeed any other
>>>     date. Our ignorance of a fact does not make that fact any less
>>>     true.
>>>
>>>     And even in a tensed language, we *can* speak of the future. We
>>>     can even speak of futures that we believe will not exist: this
>>>     happens all the time in planning, for example, where a reasoner
>>>     might decide to not do something because it forsees that if it
>>>     does do it, bad things will happen. So the present cannot be a
>>>     bound. So what is the bound?
>>>
>>>>     Some relationships have narrower extents in time than those two
>>>>     bounds, and some relationships have multiple discontinuous
>>>>     extents in time, but there's no place in a triple to describe
>>>>     those. Why? A similar idea applies to space, some relationships
>>>>     are only true in specific regions of space.
>>>
>>>     I wonder, do you realize that you are not just arguing with RDF
>>>     here, but with close to 1.5 centuries of formal philosophy of
>>>     logic? Ever since Prior first described tense as a
>>>     modality, tensed modal logics have been a clear subfield, but
>>>     AFAIK nobody has concluded that all of logic must be tensed
>>>     (still less spatially situated), or that the notion of truth is
>>>     itself inherently temporal in nature.
>>>
>>>>
>>>>     I believe a fix for this
>>>
>>>     As the proverb says, if it ain't broken, don't fix it.
>>>
>>>     Pat
>>>
>>>>     would be optional time and space positions that can be left
>>>>     blank if not required:
>>>>
>>>>         Subject Relation Object T1 T2 SpatialBound
>>>>
>>>>     With that, event ambiguity is resolved without the need for
>>>>     event IDs.
>>>>
>>>>     I'll go into it in another email, but the temporal range should
>>>>     ideally be inclusive-start and exclusive-end, so some of my
>>>>     earlier examples actually need correction around that.
>>>>
>>>>     Here's a more complex example that involves both time and space
>>>>     and builds on an example I gave at the beginning of the thread:
>>>>
>>>>     Using existing RDF-Star, and mimicking how others appear to be
>>>>     using it:
>>>>
>>>>     :BigMac :price-USD 5.66
>>>>         {|
>>>>             :quantitySold 550000000
>>>>             :statedIn :Wikipedia
>>>>             :region :UnitedStates
>>>>             :startTime 2021
>>>>             :endTime 2022
>>>>         |}
>>>>
>>>>     Which expands to:
>>>>
>>>>     :BigMac :price-USD 5.66
>>>>     << :BigMac :price-USD 5.66 >> :quantitySold 550000000
>>>>     << :BigMac :price-USD 5.66 >> :statedIn :Wikipedia
>>>>     << :BigMac :price-USD 5.66 >> :region :UnitedStates
>>>>     << :BigMac :price-USD 5.66 >> :startTime 2021
>>>>     << :BigMac :price-USD 5.66 >> :endTime 2022
>>>>
>>>>     There's so much ambiguity in both of the above. If the original
>>>>     intention was to describe the quantity sold in that specific
>>>>     region during that specific time then I think the expansion
>>>>     breaks that, or at the very least leaves it open to be broken
>>>>     by further statements if the price ever happens to be the same
>>>>     in a different period of time or a different region. Also, if
>>>>     the original intention was to say that all of the information
>>>>     was stated in Wikipedia, then I think the expansion breaks that
>>>>     too.
>>>>
>>>>     A better way might be to use optional time and space positions
>>>>     and a "complex statement", which handily also results in
>>>>     metadata being separated from additional data:
>>>>
>>>>     :BigMac :price-USD 5.66 2021 2022 :UnitedStates
>>>>         { :quantitySold 550000000 }
>>>>         {| :statedIn :Wikipedia |}
>>>>
>>>>     Which expands to:
>>>>
>>>>     :BigMac :price-USD 5.66 2021 2022 :UnitedStates
>>>>     { :BigMac :price-USD 5.66 2021 2022 :UnitedStates }
>>>>     :quantitySold 550000000
>>>>     << :BigMac :price-USD 5.66 2021 2022 :UnitedStates >> :statedIn
>>>>     :Wikipedia
>>>>     << { :BigMac :price-USD 5.66 2021 2022 :UnitedStates }
>>>>     :quantitySold 550000000 >> statedIn :Wikipedia
>>>>
>>>>     Even though this is a complex example, I think the time/space
>>>>     ambiguity and metadata ambiguity are both gone now.
>>>>
>>>>     In summary, I feel like time and space positions should exist
>>>>     in RDF and it would fix some of the problems in RDF-Star too.
>>>>
>>>>     Regards
>>>>     Anthony
>>>>
>>>>
>>>>     On Sat, Jan 15, 2022 at 1:48 PM Anthony Moretti
>>>>     <anthony.moretti@gmail.com> wrote:
>>>>     I see your point, and I believe that's a valid approach. But I
>>>>     am not sure everyone wants to commit to that kind of
>>>>     ontological detail. As I wrote in my previous mail: conflating
>>>>     past and future event into the same class works well for many
>>>>     practical use cases.
>>>>
>>>>     I agree. And, as Pete described, if the classification is
>>>>     important to a reasoner it can be done by the reasoner anyway.
>>>>     My point was just to say that implicit temporal bounds
>>>>     still seem to exist even for that very difficult example, and,
>>>>     by doing that, I was trying to chop away at reasons for not
>>>>     having optional time and space positions.
>>>>
>>>>     In fact, optional time and space positions might actually help
>>>>     when describing future events because they let you easily set
>>>>     expiry dates for the things you say. For example, if you
>>>>     were planning WebConf2022 and the dates for it were still
>>>>     changing you could release a statement that was valid for only
>>>>     a certain period of time:
>>>>
>>>>     :WebConf2022 :startDate "2022-04-25"^^xsd:date 2022-01-15
>>>>     2022-01-21
>>>>
>>>>     And then if plans change the following week and the event gets
>>>>     pushed back a month, which is happening a lot right now for
>>>>     in-person events (I know WebConf2022 is online), you could
>>>>     release an updated statement that was valid for a new period of
>>>>     time:
>>>>
>>>>     :WebConf2022 :startDate "2022-05-23"^^xsd:date 2022-01-22
>>>>     2022-01-28
>>>>
>>>>>     Aside from modeling simplicity, I think the other major
>>>>>     argument for time and space positions is that order of
>>>>>     assertion matters.
>>>>     ??
>>>>
>>>>     Not in RDF, it does not.
>>>>
>>>>
>>>>     I don't want to say I'm certain of this, but I think for
>>>>     triples that are time/space dependent and then used as the
>>>>     subject or object of another statement (in plain RDF via the
>>>>     use of identifiers) it does seem to matter. The triple needs to
>>>>     be completed first for further statements to make sense, and I
>>>>     think RDF-Star exposes the problem. If that's not the case can
>>>>     someone please give me a counterexample?
>>>>
>>>>     The "Thomas traveling to Paris" example is a modification of an
>>>>     example Thomas gave in a different thread, and I'm dropping it
>>>>     because, as Pete also notices, it has various issues. The
>>>>     following example (Obama's first term in office) is an example
>>>>     I'm creating myself, but I'm sure people are going to try and
>>>>     do stuff like this because it's already happening with
>>>>     the celebrity marriage example:
>>>>
>>>>     :BarackObama :presidentOf :UnitedStates
>>>>         {|
>>>>             :statedIn :Wikipedia
>>>>             :startTime 2009
>>>>             :endTime 2013
>>>>         |}
>>>>
>>>>     What was stated in Wikipedia? The incomplete triple or the one
>>>>     completed by the temporal constraints? I think what is meant is
>>>>     the following, with the temporal constraints stated first and
>>>>     as additional data rather than metadata:
>>>>
>>>>     :BarackObama :presidentOf :UnitedStates
>>>>         {
>>>>             :startTime 2009
>>>>             :endTime 2013
>>>>         }
>>>>         {| :statedIn :Wikipedia |}
>>>>
>>>>     Even if the above format were available, people would probably
>>>>     still try to do something like:
>>>>
>>>>     :BarackObama :presidentOf :UnitedStates
>>>>         {
>>>>             :secretaryOfState :HillaryClinton
>>>>             :startTime 2009
>>>>             :endTime 2013
>>>>         }
>>>>         {| :statedIn :Wikipedia |}
>>>>
>>>>     But if the temporal constraints aren't asserted first you have
>>>>     a similar issue upon expansion because HillaryClinton wasn't
>>>>     Secretary of State for his entire presidency, only for his
>>>>     first term.
>>>>
>>>>     Having optional time and space positions makes the order of
>>>>     assertion clear and the time-dependent triple is completed
>>>>     first before further statements are made. Separating additional
>>>>     data from metadata does the same thing and clarifies what the
>>>>     metadata is about:
>>>>
>>>>     :BarackObama :presidentOf :UnitedStates 2009 2013
>>>>         { :secretaryOfState :HillaryClinton }
>>>>         {| :statedIn :Wikipedia |}
>>>>
>>>>     RDF(-star) has no such notion. Assuming that what you wrote
>>>>     above is supposed to be RDF-star (replacing curly brackets with
>>>>     double angle brackets), then the semantics of RDF-star
>>>>     (directly inherited from RDF) requires that all four statements
>>>>     are interpretable independently of each other, and are all
>>>>     considered true (assuming that you "trust"/"accept" the whole
>>>>     graph as true).
>>>>
>>>>     So I guess what I'm saying is that some triples, time/space
>>>>     dependent ones, don't stand on their own and can't be
>>>>     considered true or false, and instead of telling people to
>>>>     avoid them, or telling people to avoid forms like the above
>>>>     whose expansion will include incomplete triples, let's embrace
>>>>     them and design a solution for them. Bonus points that it's a
>>>>     super simple way to model things so it's great for beginners,
>>>>     bonus points that it also handles reoccurring events, bonus
>>>>     points that it solves for our other dimension, space, at the
>>>>     same time.
>>>>
>>>>     To answer this question, we need to precisely specify the
>>>>     meaning of each term of the used ontology. Since this is your
>>>>     example, I would expect you to know... :-)
>>>>
>>>>     The original example is Thomas', but aside from that, if
>>>>     there's ambiguity due to the chosen tense for the relation,
>>>>     which ideally shouldn't be a factor, then a lot of that goes
>>>>     away when you have valid times and can then opt for, say,
>>>>     present tense all of the time and have everything still be
>>>>     clear. The point I was trying to make though was that the
>>>>     triples were examples of the above, incomplete triples that
>>>>     need time/space information to complete them.
>>>>
>>>>     But more importantly, I reiterate my request to be explicit
>>>>     about what you mean when you write "statement". Each RDF triple
>>>>     makes a statement, that IS either true or false. However, a
>>>>     given set of RDF triples might give an description of something
>>>>     else (e.g. an anthony-statement) that might be deemed
>>>>     *incomplete* for some uses.
>>>>
>>>>     Once we have a clear distinction between rdf-statement and
>>>>     anthony-statement, then we can discuss whether a given set of
>>>>     rdf-statements provides a complete and accurate description of
>>>>     a given anthony-statement.
>>>>
>>>>
>>>>     I'm still not clear what you mean by this, but I'll try to
>>>>     understand. Of the four statement types I proposed the closest
>>>>     to an RDF triple is a "Simple statement", which ideally
>>>>     would just be an RDF triple with optional time and space
>>>>     positions and the ability to have any type of statement as
>>>>     subject or object. A given set of simple statements, which
>>>>     would be provided using a compound statement that also has
>>>>     optional time and space positions, could then provide a
>>>>     complete and accurate description of any of the other statement
>>>>     types. Is that an answer to your question? Sorry if I've still
>>>>     misunderstood.
>>>>
>>>>     Regards
>>>>     Anthony
>>>>
>>>>     On Sat, Jan 15, 2022 at 2:26 AM Pete Rivett
>>>>     <pete.rivett@agnos.ai> wrote:
>>>>     I'd still take a modeling approach rather than ad hoc use of
>>>>     rdf-star annotations (which, as I pointed out in my last email,
>>>>     we have no way of documenting a schema for).
>>>>
>>>>     From a modeling point of view I'd argue:
>>>>     a) for modeling WebConf2022 as a simple Event. You could
>>>>     additionally and dynamically add the class FutureEvent using
>>>>     the restriction :startTime > now(). And, indeed PastEvent where
>>>>     :endTime < now().
>>>>     if needed you could have an additional property :status with
>>>>     values appropriate to your interest in its lifecycle such as
>>>>     :Conceived, :Resourced, :Committed, :Announced, :Started,
>>>>     :Completed, :ProceedingsPublished.
>>>>
>>>>     b) if you're interested in multiple journeys why not actually
>>>>     model them:
>>>>      _journey1 a :Journey ;
>>>>       :traveler :Thomas ;
>>>>       :destination :Paris ;
>>>>       :timing [a :Period;
>>>>           :start T1 ;
>>>>           :end :T2
>>>>       ]
>>>>     (you probably want an :origin place too)
>>>>
>>>>     Generally I'd caution against trying to use Fictional: it
>>>>     becomes very subjective. For example is Klingon
>>>>     https://en.wikipedia.org/wiki/Klingon_language a fictional
>>>>     language? It originated in a fictional TV series but it has
>>>>     real speakers, works of literature and a language institute.
>>>>     And an official ISO language code (@tlh). If Klingon is
>>>>     fictional then why is Esperanto not?
>>>>
>>>>     Pete
>>>>
>>>>     On Thu, 13 Jan 2022 at 18:40, Anthony Moretti
>>>>     <anthony.moretti@gmail.com> wrote:
>>>>     Earlier Pierre-Antoine wrote:
>>>>
>>>>     Ok, let's take another example:
>>>>
>>>>     :theWebConf2022 a s:Event ;
>>>>         s:startDate "2022-04-25"^^xsd:date ;
>>>>         s:endDate "2022-04-29"^^xsd:date .
>>>>
>>>>     would you consider that those triple will only be valid on
>>>>     2022-04-25? Or would you argue that this event already exists,
>>>>     even though it has not occurred yet?
>>>>
>>>>
>>>>     This is a great discussion because I don't think time has been
>>>>     given the attention it deserves. The following are my current
>>>>     thoughts, I'm happy to hear more opinions though.
>>>>
>>>>     There's a saying "the future is fiction until it happens". We
>>>>     can definitely talk about fictional things, Fabio gives the
>>>>     example of Mickey Mouse but you can even include abstract
>>>>     things like numbers, they're mental concepts and I'd argue that
>>>>     the concepts exist from the moment they're imagined. We can
>>>>     talk about fictional things without problem as long as it's
>>>>     understood that they're fictional, this can be explicit by
>>>>     saying Mickey Mouse is a FictionalCharacter, or implicit when
>>>>     talking about abstract things like numbers. You could create a
>>>>     hierarchy for fictional things by duplicating schema-org and
>>>>     prefixing all of the class names with "Fictional":
>>>>
>>>>     Thing
>>>>         Person
>>>>         Place
>>>>         Event
>>>>
>>>>     FictionalThing
>>>>         FictionalPerson
>>>>         FictionalPlace
>>>>         FictionalEvent
>>>>
>>>>     I'd argue that past events belong in the first hierarchy and
>>>>     future events belong in the second, like so:
>>>>
>>>>     FictionalThing
>>>>         FictionalEvent
>>>>             FutureEvent
>>>>
>>>>     Pat mentioned Tarskian truth conditions, and I think the
>>>>     WebConf2022 example fails that, even though it's convenient to
>>>>     describe it like that because it matches how you'd describe
>>>>     past WebConfs. It might be more accurate to say:
>>>>
>>>>     :WebConf2021 a :Event
>>>>         :startDate 2021-04-19
>>>>         :endDate 2021-04-23
>>>>
>>>>     :WebConf2022 a :FutureEvent
>>>>         :scheduledStartDate 2022-04-25
>>>>         :scheduledEndDate 2022-04-29
>>>>
>>>>     And only once the event has happened, and a reality has
>>>>     occurred that can be described, describe it in the first manner
>>>>     like WebConf2021.
>>>>
>>>>     Like I said, I'm happy to hear more opinions on all of this though.
>>>>
>>>>     So I am still not convinced that triples are the right level of
>>>>     granularity for systematically attaching contextual metadata.
>>>>     Following Pat, I prefer to keep rdf-statements dead-simple (1),
>>>>     and model more complex things (like anthony-statements) with a
>>>>     bunch of triples.
>>>>
>>>>     Aside from modeling simplicity, I think the other major
>>>>     argument for time and space positions is that order of
>>>>     assertion matters. If people annotate with start and end
>>>>     times, which they're already doing, then expansions don't work
>>>>     correctly. Going with an earlier example:
>>>>
>>>>     :Thomas :travelingTo :Paris
>>>>         {
>>>>             :by :Train,
>>>>             :startTime T1,
>>>>             :endTime T2,
>>>>         }
>>>>
>>>>     Would expand to:
>>>>
>>>>     :Thomas :travelingTo :Paris
>>>>     { :Thomas :travelingTo :Paris } :by :Train
>>>>     { :Thomas :travelingTo :Paris } :startTime T1
>>>>     { :Thomas :travelingTo :Paris } :endTime T2
>>>>
>>>>     The first statement is incomplete, neither true or false, and
>>>>     the second statement has an incomplete statement as subject.
>>>>     What do either of those statements mean? Maybe someone has a
>>>>     better idea, but the only way I currently see around it would
>>>>     be custom expansion rules to do with time and space, which
>>>>     seems ugly to me.
>>>>
>>>>     With time and space positions it would start as:
>>>>
>>>>     :Thomas :travelingTo :Paris T1 T2
>>>>         { :by :Train }
>>>>
>>>>     Which expands to:
>>>>
>>>>     :Thomas :travelingTo :Paris T1 T2
>>>>     { :Thomas :travelingTo :Paris T1 T2 } :by :Train
>>>>
>>>>     Regards
>>>>     Anthony
>>>>
>>>>     On Fri, Jan 14, 2022 at 12:19 PM Pete Rivett
>>>>     <pete.rivett@agnos.ai> wrote:
>>>>     Fabio, I don't know if it was deliberate, but it seems to me
>>>>     that using different preciates to bound periods such as :start,
>>>>     :end, :after, :before (and more?) seems to defeat the point
>>>>     (and I think what Anthony was looking for) to allow
>>>>     predictable querying and reasoning.
>>>>     I really think it's premature for rdf-star to embody anything
>>>>     like this. I think we should start with a best practice note as
>>>>     suggested (even that will I think be hard enough to reach
>>>>     consensus on), then after sufficient demonstrated success with
>>>>     applying it for real, we could consider standardizing a
>>>>     specific set of predicates in a separate schema.
>>>>     Which also invites the question "what would a schema for
>>>>     rdf-star annotation properties look like, and how could you
>>>>     specify the (required/permitted) use
>>>>     of specific annotation properties with
>>>>     specific regular properties?".
>>>>
>>>>     BTW nary relationships need not need be as complex as your
>>>>     examples. Simpler alternatives:
>>>>     _:item1 a :temporaryLocation;
>>>>          :affects :MonaLisa;
>>>>          :location :Florence;
>>>>          :hasPeriod [
>>>>            :start  "1506"^^xsd:Year;
>>>>            :end  "1517"^^xsd:Year;
>>>>          ] .
>>>>
>>>>     _item1 a :USPresidency [
>>>>        :holder :RichardNixon;
>>>>        :hasPeriod [
>>>>         :start "1969-01-20"^^xsd:dateTime ;
>>>>         :end "1974-08-09"^^xsd:dateTime.
>>>>     ]
>>>>
>>>>     Cheers,
>>>>     Pete
>>>>
>>>>     On Thu, 13 Jan 2022 at 09:48, Fabio Vitali
>>>>     <fabio.vitali@unibo.it> wrote:
>>>>     Hi!
>>>>
>>>>     > On 13 Jan 2022, at 17:04, Pierre-Antoine Champin
>>>>     <pierre-antoine.champin@ercim.eu> wrote:
>>>>     >
>>>>     > Hi Anthony,
>>>>     >
>>>>     > you wrote
>>>>     >
>>>>     > > that the temporal validity of any statement is implicitly
>>>>     lower-bounded by the existence of the things that it talks
>>>>     about,       so technically the birth-date example is only
>>>>     valid after the birth date of the person
>>>>     >
>>>>     > Ok, let's take another example:
>>>>     >
>>>>     > :theWebConf2022 a s:Event ;
>>>>     >     s:startDate "2022-04-25"^^xsd:date ;
>>>>     >     s:endDate "2022-04-29"^^xsd:date .
>>>>     >
>>>>     > would you consider that those triple will only be valid on
>>>>     2022-04-25? Or would you argue that this event already exists,
>>>>     even though it has not occurred yet?
>>>>     >
>>>>     > Without starting to count angels on pinpoints (wondering if a
>>>>     yet-to-be-born person exists or not), let's be pragmatic: does
>>>>     it make your knowledge base inconsistent in any way to consider
>>>>     that such triples about future events are already valid? I
>>>>     don't think so.
>>>>
>>>>     You are adding two more pairs of terms, "valid / non valid" and
>>>>     "exist / not exist", to an already complex issue. The pairs
>>>>     already in play are:
>>>>
>>>>     1) true / false (or not-true?)
>>>>     2) asserted / not-asserted.
>>>>
>>>>     True / not true attain to the relationship between statements
>>>>     and reality (or at least some notion of reality endorsed by
>>>>     logicians and a few mathematicians). Asserted / not asserted
>>>>     attain to whether we know that the current dataset contains
>>>>     the statement or not.
>>>>
>>>>     [ Valid / not valid attain to correctness in expressing
>>>>     statements (e.g., according to an ontology), and exist /not
>>>>     exist attain to physical or philosophical understanding of
>>>>     reality which makes my mind quiver (Does Mickey Mouse exist?). ]
>>>>
>>>>     I understand that here is a traditional, albeit vague,
>>>>     connection in this community between asserted and true, which I
>>>>     respect and uphold. But whatever is the contrary of true, I do
>>>>     not think there should be a similar connection between
>>>>     non-asserted and false (or not true).
>>>>
>>>>     Non-asserted triples can be absolutely true (<< :theWebConf
>>>>     dc:subject :webTechnologies >>), absolutely false (<<
>>>>     :theWebConf :frontFor :mossadRecruitment >> ), and
>>>>     conditionally true (<< :theWebConf :rating :FiveStars >> ),
>>>>     depending on a lot of factors (time, location,
>>>>     provenance, confidence, etc.), and since rdf-star allows us to
>>>>     represent triples without asserting them, we can use it to
>>>>     express facts about non-asserted triples without worrying about
>>>>     their actual truth:
>>>>
>>>>     << :theWebConf dc:subject :webTechnologies >>   :accordingTo
>>>>     :wikipedia.
>>>>     << :theWebConf :frontFor  :mossadRecruitment >> :accordingTo
>>>>     :someMadman.
>>>>     << :theWebConf :rating    :FiveStars >>         :accordingTo
>>>>     :FabioVitali.
>>>>
>>>>     These triples are all asserted (and true (and valid!))
>>>>     regardless of the truth value of their quoted triples. This is
>>>>     exactly what makes rdf-star very interesting to me.
>>>>
>>>>     Now, using :theWebConf as in your example is somewhat
>>>>     misleading: you are using an Event, which is an abstract
>>>>     concept of something whose main characteristic is being
>>>>     temporally and geographically constrained, and then you ask if
>>>>     there are other temporal constraints associated to it. No, no,
>>>>     probably not. But you put yourself in an easy situation.
>>>>
>>>>     Let's try with entities which are not events: say, a physical
>>>>     object, a role, a relationship:
>>>>
>>>>     << :monaLisa :location :Florence >>
>>>>     << :USA :president :RichardNixon >>
>>>>     << :MickeyMouse inLoveWith :MinnieMouse >>
>>>>
>>>>     All these triples are NOT absolutely true, and at the same time
>>>>     they are NOT absolutely false, either.
>>>>
>>>>     Using rdf-star, we can create absolutely-true statements out of
>>>>     these non-absolutely-true triples:
>>>>
>>>>     << :monaLisa :location :Florence >> :after "1506"^^xsd:Year;
>>>>     :before "1517"^^xsd:Year .
>>>>     << :USA :president :RichardNixon >> :start "1969"^^xsd:Year;
>>>>     :end "1974"^^xsd:Year .
>>>>     << :MickeyMouse inLoveWith :MinnieMouse >> :accordingTo
>>>>     :WaltDisney .
>>>>
>>>>     These are trivial rdf-star representations of (simple)
>>>>     anthony-statements (syntax aside). I fail to see a downside to
>>>>     this.
>>>>
>>>>     The opposite, to adopt "dead-simple statements" seems much
>>>>     worse to me: adopting n-ary relationships and events and states
>>>>     and opinions seems SO MUCH MORE COMPLICATED:
>>>>
>>>>     _:item1 a :temporaryLocation;
>>>>          :affects :monaLisa;
>>>>          :location :Florence;
>>>>          :start [
>>>>              a :uncertainDate ;
>>>>              :after "1506"^^xsd:Year;
>>>>          ] ;
>>>>          :end [
>>>>              a :uncertainDate ;
>>>>              :before "1517"^^xsd:Year;
>>>>          ] .
>>>>
>>>>     _:item2 a :temporaryState;
>>>>          :role :presidency;
>>>>          :organization :USA;
>>>>          :holder :RichardNixon;
>>>>          :startingEvent [
>>>>             a :election;
>>>>             :date "1969-01-20"^^xsd:dateTime.
>>>>          ];
>>>>          :endingEvent [
>>>>             a :resignation;
>>>>             :date "1974-08-09"^^xsd:dateTime.
>>>>           ].
>>>>
>>>>     _:item3 a :fictitiousCouple;
>>>>          :member :MickeyMouse;
>>>>          :member :MinnieMouse;
>>>>          :type :Love;
>>>>          :inventedBy :WaltDisney.
>>>>
>>>>     You may feel safer with n-ary relationships, i.e. with the
>>>>     objectification of relationships into abstract entities, but
>>>>     another way to express this concept is as "reification of
>>>>     triples into blank nodes" which seems to me exactly what
>>>>     rdf-star is about.
>>>>
>>>>     We have rdf-star. Let's use it.
>>>>
>>>>     Ciao
>>>>
>>>>     Fabio
>>>>
>>>>     >
>>>>     > So I am still not convinced that triples are the right level
>>>>     of granularity for systematically attaching contextual
>>>>     metadata. Following Pat, I prefer to keep rdf-statements
>>>>     dead-simple (1), and model more complex things (like
>>>>     anthony-statements) with a bunch of triples.
>>>>     >
>>>>     >   pa
>>>>     >
>>>>     > (1) even if, arguably, RDF-star makes them a little more
>>>>     complex that they originally were.
>>>>     >
>>>>     > On 13/01/2022 03:51, Anthony Moretti wrote:
>>>>     >> Earlier I wrote:
>>>>     >> the temporal validity of any statement is implicitly
>>>>     lower-bounded by the existence of the things that it talks about
>>>>     >>
>>>>     >> I wouldn't mind some feedback on this, but I think the
>>>>     temporal validity of every statement has an implicit upper
>>>>     bound too:
>>>>     >>
>>>>     >> Implicit lower bound: Existence of the things being described.
>>>>     >> Implicit upper bound: Stated time of assertion, otherwise
>>>>     the present.
>>>>     >>
>>>>     >> If that's correct, I can use it to demonstrate optional time
>>>>     and space positions:
>>>>     >>
>>>>     >> It's 2010, and Pierre-Antoine sends me a graph. He puts a
>>>>     timestamp on his graph by upper-bounding the temporal validity:
>>>>     >>
>>>>     >> {
>>>>     >>     :BarackObama :presidentOf :UnitedStates 2009 _,
>>>>     >>     :JoeBiden :vicePresidentOf :UnitedStates 2009 _,
>>>>     >>     :HillaryClinton :secretaryOfStateOf :UnitedStates 2009 _,
>>>>     >> }
>>>>     >>     _ 2010
>>>>     >>
>>>>     >> It's now 2022, and I'm working on my own graph:
>>>>     >>
>>>>     >> {
>>>>     >>     :JoeBiden :presidentOf :UnitedStates 2021 _,
>>>>     >>     :KamalaHarris :vicePresidentOf :UnitedStates 2021 _,
>>>>     >>     :AntonyBlinken :secretaryOfStateOf :UnitedStates 2021 _,
>>>>     >> }
>>>>     >>
>>>>     >> I trust Pierre-Antoine and remember that he sent me a graph
>>>>     a long time ago. I do the laziest thing possible and import it
>>>>     unmodified as a compound statement. The information is
>>>>     incomplete but the OWA means everything is ok, and the graph is
>>>>     still valid:
>>>>     >>
>>>>     >> {
>>>>     >>     {
>>>>     >>         :BarackObama :presidentOf :UnitedStates 2009 _,
>>>>     >>         :JoeBiden :vicePresidentOf :UnitedStates 2009 _,
>>>>     >>         :HillaryClinton :secretaryOfStateOf :UnitedStates
>>>>     2009 _,
>>>>     >>     }
>>>>     >>         _ 2010,
>>>>     >>     :JoeBiden :presidentOf :UnitedStates 2021 _,
>>>>     >>     :KamalaHarris :vicePresidentOf :UnitedStates 2021 _,
>>>>     >>     :AntonyBlinken :secretaryOfStateOf :UnitedStates 2021 _,
>>>>     >> }
>>>>     >>
>>>>     >> I do automated flattening of the graph. The information is
>>>>     incomplete, but the graph is still valid:
>>>>     >>
>>>>     >> {
>>>>     >>     :BarackObama :presidentOf :UnitedStates 2009 2010,
>>>>     >>     :JoeBiden :vicePresidentOf :UnitedStates 2009 2010,
>>>>     >>     :HillaryClinton :secretaryOfStateOf :UnitedStates 2009 2010,
>>>>     >>     :JoeBiden :presidentOf :UnitedStates 2021 _,
>>>>     >>     :KamalaHarris :vicePresidentOf :UnitedStates 2021 _,
>>>>     >>     :AntonyBlinken :secretaryOfStateOf :UnitedStates 2021 _,
>>>>     >> }
>>>>     >>
>>>>     >> I finally get the motivation and I update Pierre Antoine's
>>>>     statements. The information is now up to date and the graph is
>>>>     still valid:
>>>>     >>
>>>>     >> {
>>>>     >>     :BarackObama :presidentOf :UnitedStates 2009 2017,
>>>>     >>     :JoeBiden :vicePresidentOf :UnitedStates 2009 2017,
>>>>     >>     :HillaryClinton :secretaryOfStateOf :UnitedStates 2009 2013,
>>>>     >>     :JoeBiden :presidentOf :UnitedStates 2021 _,
>>>>     >>     :KamalaHarris :vicePresidentOf :UnitedStates 2021 _,
>>>>     >>     :AntonyBlinken :secretaryOfStateOf :UnitedStates 2021 _,
>>>>     >> }
>>>>     >>
>>>>     >> I decide to send it back to Pierre-Antoine, and I put a
>>>>     timestamp on my graph:
>>>>     >>
>>>>     >> {
>>>>     >>     :BarackObama :presidentOf :UnitedStates 2009 2017,
>>>>     >>     :JoeBiden :vicePresidentOf :UnitedStates 2009 2017,
>>>>     >>     :HillaryClinton :secretaryOfStateOf :UnitedStates 2009 2013,
>>>>     >>     :JoeBiden :presidentOf :UnitedStates 2021 _,
>>>>     >>     :KamalaHarris :vicePresidentOf :UnitedStates 2021 _,
>>>>     >>     :AntonyBlinken :secretaryOfStateOf :UnitedStates 2021 _,
>>>>     >> }
>>>>     >>     _ 2022
>>>>     >>
>>>>     >> And so it could continue. Spatial validity would be handled
>>>>     similarly.
>>>>     >>
>>>>     >> It's very easy to reason about temporal/spatial validity
>>>>     when the approach to statements is unified and optional time
>>>>     and space positions can be used everywhere.
>>>>     >>
>>>>     >> Regards
>>>>     >> Anthony
>>>>     >>
>>>>     >> On Wed, Jan 12, 2022 at 12:48 PM Anthony
>>>>     Moretti <anthony.moretti@gmail.com> wrote:
>>>>     >> Correction, I was a bit sloppy:
>>>>     >>
>>>>     >> In both cases I would leave the time and space positions
>>>>     blank anyway, so RDF-as-usual.
>>>>     >>
>>>>     >> In the second example the space position would be blank, but
>>>>     not the time positions. I was just trying to agree that yes the
>>>>     second example isn't place-dependent.
>>>>     >>
>>>>     >> Regards
>>>>     >> Anthony
>>>>     >>
>>>>     >> On Wed, Jan 12, 2022 at 12:44 PM Anthony
>>>>     Moretti <anthony.moretti@gmail.com> wrote:
>>>>     >> Hi Pierre-Antoine
>>>>     >> What is not entirely clear to me is how you see the ideas
>>>>     below interact with RDF-star —or RDF, for that matter...
>>>>     >>
>>>>     >> 1) Do you want to modify the core of RDF / RDF-star,
>>>>     replacing their notion of statement by the one you propose here
>>>>     (time+place annotated, complex and/or compound)?
>>>>     >>
>>>>     >> 2) Or do you want to explore how your proposed notion of
>>>>     statement could be expressed *on top* of RDF / RDF-star, with
>>>>     no or minimal modification to them?
>>>>     >>
>>>>     >> If the answer is 2 (my favorite option, by the way), then
>>>>     the idea is to model anthony-statements using a set of
>>>>     rdf-statements (possibly extended with RDF-star).
>>>>     >>
>>>>     >>
>>>>     >> Ideally:
>>>>     >> RDF: Time and space positions.
>>>>     >> RDF-Star: Simple, compound, and complex statements.
>>>>     >>
>>>>     >> It would be ideal to put the time and space positions at the
>>>>     RDF level because, as Pat and Fabio seem to agree, some triples
>>>>     are time/space dependent and make no sense without that
>>>>     information. They're not edge cases either, it might seem like
>>>>     that because so far there hasn't been a way to express them,
>>>>     but there are infinitely many just as there are infinitely many
>>>>     that aren't time/space constrained. Also, the order of
>>>>     assertion is important for time/space dependent triples, if
>>>>     anything is to be said about them, additional data or metadata,
>>>>     then the time/space constraints need to be asserted first, and
>>>>     time and space positions ensure that order of assertion.
>>>>     >>
>>>>     >> I think it would help the discussion a lot to a) acknowledge
>>>>     that the word "statement" in this discussion is ambiguous, and
>>>>     b) to be as explicit as possible about which kind we are
>>>>     talking about.
>>>>     >>
>>>>     >> I'm using the word "statement" as a direct replacement for
>>>>     "sentence", so maybe "sentence" is a better term:
>>>>     >>
>>>>     >> sentence:
>>>>     >> a set of words that is complete in itself, typically
>>>>     containing a subject and predicate, conveying a statement,
>>>>     question, exclamation, or command, and consisting of a main
>>>>     clause and sometimes one or more subordinate clauses.
>>>>     >>
>>>>     >> I am uncomfortable with "hard-coding" these 4 dimensions,
>>>>     and only them, in every possible statement. I think that the
>>>>     relevant dimensions depend on the relation itself (e.g., the
>>>>     birth-date of a person is neither time nor place dependent; the
>>>>     president of a country is not place dependent...). And I don't
>>>>     think that any list of contextual dimension can be exhaustive.
>>>>     >>
>>>>     >> Especially regarding certainty, there are many ways to model
>>>>     uncertainty (not all of them modelling it with a single value
>>>>     between 0 and 1, by the way).
>>>>     >>
>>>>     >>
>>>>     >> On the first example you gave, my thoughts are that the
>>>>     temporal validity of any statement is implicitly lower-bounded
>>>>     by the existence of the things that it talks about, so
>>>>     technically the birth-date example is only valid after the
>>>>     birth date of the person, the birth date happens to be the
>>>>     object of the statement in this case but the idea would apply
>>>>     to any statement. On the second example, yes I agree
>>>>     its spatial validity is unbound. In both cases I would leave
>>>>     the time and space positions blank anyway, so RDF-as-usual.
>>>>     >>
>>>>     >> I'm happy to drop "certainty" for the reasons you stated.
>>>>     I've included it so far because it's another example of where
>>>>     order of assertion becomes important, for it to make sense it
>>>>     needs to be asserted after time and space but before
>>>>     metadata. But yes, let's drop it for now.
>>>>     >>
>>>>     >> And yes for sure, no list of contextual dimensions can be
>>>>     exhaustive, but if time and space positions are allowed it
>>>>     ensures those assertions are made first and the whole framework
>>>>     becomes scalable and easier to reason about.
>>>>     >>
>>>>     >> Do you have any clear definition, or at least guidelines, to
>>>>     decide whether a piece of information is additional data or
>>>>     metadata?
>>>>     >>
>>>>     >> My quick take would be: additional data continues the
>>>>     description, whereas metadata is description of the description.
>>>>     >>
>>>>     >> No widespread need, but logically it could continue,
>>>>     descriptions of descriptions of descriptions and so on:
>>>>     >>
>>>>     >> Simple statement
>>>>     >>     { Additional data }
>>>>     >>     {| First-order metadata |}
>>>>     >>     {| Second-order metadata |}
>>>>     >>     ...
>>>>     >>
>>>>     >> Fabio has a good idea with the note containing examples of
>>>>     good modeling.
>>>>     >>
>>>>     >> Regards
>>>>     >> Anthony
>>>>     >>
>>>>     >> On Wed, Jan 12, 2022 at 8:02 AM Fabio Vitali
>>>>     <fabio.vitali@unibo.it> wrote:
>>>>     >> Dear Pierre-Antoine,
>>>>     >>
>>>>     >> > 1) Do you want to modify the core of RDF / RDF-star,
>>>>     replacing their notion of statement by the one you propose here
>>>>     (time+place annotated, complex and/or compound)?
>>>>     >>
>>>>     >>
>>>>     >> I think with you that RDFstar already provides a lot of what
>>>>     has been discussed so far.
>>>>     >>
>>>>     >> Yet Anthony explicitly mentions (and I agree with him) that
>>>>     RDFstar has the right approach for single triples, but is
>>>>     lacking in supporting the needs for complex and compound
>>>>     statements. Working towards some suggestions to integrate
>>>>     these needs would enrich and complete the RDFstar proposal.
>>>>     >>
>>>>     >> My preference would go towards exploiting named graphs,
>>>>     explicitly introducing unasserted named graphs that can then be
>>>>     used in RDFstar in the same way of unasserted triples.
>>>>     >>
>>>>     >> > 2) Or do you want to explore how your proposed notion of
>>>>     statement could be expressed *on top* of RDF / RDF-star, with
>>>>     no or minimal modification to them?
>>>>     >>
>>>>     >> I do not know Anthony's point of view on this, but I believe
>>>>     that it would be useful to think of a resource providing some
>>>>     thoughtful and general guidelines on how RDFstar's quoted and
>>>>     annotated triples (as well as, hopefully, the RDFstar's quoted
>>>>     and annotated named graphs that I envision) could help in
>>>>     expressing conditional, time-dependent, location-dependent,
>>>>     uncertain, opinionated and competing statements.
>>>>     >>
>>>>     >> What I am thinking is something like, say, a W3C note, on
>>>>     the lines of https://www.w3.org/TR/swbp-n-aryRelations/ : a
>>>>     document introducing no new features, but explaining and making
>>>>     examples on how to use the existing features in a possibly
>>>>     unexpected and innovative way.
>>>>     >>
>>>>     >> What do you think?
>>>>     >>
>>>>     >> Fabio
>>>>     >>
>>>>     >> --
>>>>     >>
>>>>     >> > On 11 Jan 2022, at 15:43, Pierre-Antoine Champin
>>>>     <pierre-antoine.champin@ercim.eu> wrote:
>>>>     >> >
>>>>     >> > Hi Anthony,
>>>>     >> >
>>>>     >> > thanks for the summary. It's hard to catch up for those of
>>>>     us who went offline during the break :-)
>>>>     >> >
>>>>     >> > On 08/01/2022 10:40, Anthony Moretti wrote:
>>>>     >> >> Hi
>>>>     >> >>
>>>>     >> >> I thought I'd put the ideas I shared during the longer
>>>>     discussion in one place to make it easier for people to read
>>>>     and give feedback. I love what's been achieved so far, I just
>>>>     want whatever is released to be the best possible thing that
>>>>     could be released.
>>>>     >> > What is not entirely clear to me is how you see the ideas
>>>>     below interact with RDF-star —or RDF, for that matter...
>>>>     >> >
>>>>     >> > 1) Do you want to modify the core of RDF / RDF-star,
>>>>     replacing their notion of statement by the one you propose here
>>>>     (time+place annotated, complex and/or compound)?
>>>>     >> >
>>>>     >> > 2) Or do you want to explore how your proposed notion of
>>>>     statement could be expressed *on top* of RDF / RDF-star, with
>>>>     no or minimal modification to them?
>>>>     >> >
>>>>     >> > If the answer is 2 (my favorite option, by the way), then
>>>>     the idea is to model anthony-statements using a set of
>>>>     rdf-statements (possibly extended with RDF-star). I think it
>>>>     would help the discussion a lot to a) acknowledge that the
>>>>     word "statement" in this discussion is ambiguous, and b) to be
>>>>     as explicit as possible about which kind we are talking about.
>>>>     >> >
>>>>     >> > I also have a few comments on the two first ideas:
>>>>     >> >
>>>>     >> >> (...)
>>>>     >> >>
>>>>     >> >> Summary:
>>>>     >> >> 1. Optional time, space, and certainty positions.
>>>>     >> > I am uncomfortable with "hard-coding" these 4 dimensions,
>>>>     and only them, in every possible statement. I think that the
>>>>     relevant dimensions depend on the relation itself (e.g., the
>>>>     birth-date of a person is neither time nor place dependent; the
>>>>     president of a country is not place dependent...). And I don't
>>>>     think that any list of contextual dimension can be exhaustive.
>>>>     >> >
>>>>     >> > Especially regarding certainty, there are many ways to
>>>>     model uncertainty (not all of them modelling it with a single
>>>>     value between 0 and 1, by the way). On that particular topic,
>>>>     you might be interested in this paper:
>>>>     https://hal.inria.fr/hal-02167174/file/Publishing_Uncertainty_on_the_Semantic_Web__Bursting_the_LOD_bubbles__Final_Version_.pdf

>>>>     >> >
>>>>     >> >> 2. Separating additional data from metadata.
>>>>     >> > Do you have any clear definition, or at least guidelines,
>>>>     to decide whether a piece of information is additional data or
>>>>     metadata?
>>>>     >> >
>>>>     >> >   best
>>>>     >> >
>>>>     >> >> 3. Simple, compound, and complex statements.
>>>>     >> >> - - -
>>>>     >> >>
>>>>     >> >> 1. Optional time, space, and certainty positions
>>>>     >> >>
>>>>     >> >> We exist in time and space, and this type of modeling
>>>>     could possibly be easier. A statement would have four optional
>>>>     positions, leaving the time and space positions blank would
>>>>     mean "unbounded", and leaving the last position blank would
>>>>     mean 1.0:
>>>>     >> >>
>>>>     >> >> Subject Relation Object T1 T2 SpatialBound Certainty
>>>>     >> >>
>>>>     >> >> Examples:
>>>>     >> >>
>>>>     >> >> :RichardB :marriedTo :LizT 1964 1974
>>>>     >> >> :RichardB :marriedTo :LizT 1975 1976
>>>>     >> >>
>>>>     >> >> :BigMac :price-USD 7.30 T1 T2 :Switzerland
>>>>     >> >> :BigMac :price-USD 1.62 T1 T2 :India
>>>>     >> >>
>>>>     >> >> If anybody has worked with temporal databases they might
>>>>     see an analogy with "valid times". By extension, the spatial
>>>>     bound could be thought of as a "valid place".
>>>>     >> >>
>>>>     >> >> 2. Separating additional data from metadata
>>>>     >> >>
>>>>     >> >> This would remove a lot of ambiguity and creates a clear
>>>>     order of assertion. It also seems to match the Wikidata data model.
>>>>     >> >>
>>>>     >> >> Example:
>>>>     >> >>
>>>>     >> >> :LizT :starredIn :JaneEyre
>>>>     >> >>     {
>>>>     >> >>         :role :HelenBurns,
>>>>     >> >>         :pay-USD 10000,
>>>>     >> >>     }
>>>>     >> >>     {|
>>>>     >> >>         :statedBy :Bob,
>>>>     >> >>         :statedIn :Wikipedia,
>>>>     >> >>     |}
>>>>     >> >>
>>>>     >> >> 3. Simple, compound, and complex statements
>>>>     >> >>
>>>>     >> >> Taking inspiration from linguistics, there could be four
>>>>     different types of statements:
>>>>     >> >>
>>>>     >> >> 1. Simple statement
>>>>     >> >> 2. Compound statement
>>>>     >> >> 3. Complex statement
>>>>     >> >> 4. Compound-complex statement
>>>>     >> >>
>>>>     >> >> Simple statement (binary relationship):
>>>>     >> >> S R O T1 T2 SB C
>>>>     >> >>
>>>>     >> >> Compound statement (graph):
>>>>     >> >> {
>>>>     >> >>     S R O T1 T2 SB C,
>>>>     >> >>     S R O T1 T2 SB C,
>>>>     >> >>     S R O T1 T2 SB C,
>>>>     >> >> }
>>>>     >> >>     T1 T2 SB C
>>>>     >> >>
>>>>     >> >> Complex statement (n-ary relationship):
>>>>     >> >> S R O T1 T2 SB C
>>>>     >> >>     {
>>>>     >> >>         R O T1 T2 SB C,
>>>>     >> >>         R O T1 T2 SB C,
>>>>     >> >>     }
>>>>     >> >>
>>>>     >> >> Compound-complex statement (n-ary relationship):
>>>>     >> >> {
>>>>     >> >>     S R O T1 T2 SB C,
>>>>     >> >>     S R O T1 T2 SB C,
>>>>     >> >>     S R O T1 T2 SB C,
>>>>     >> >> }
>>>>     >> >>     T1 T2 SB C
>>>>     >> >>     {
>>>>     >> >>         R O T1 T2 SB C,
>>>>     >> >>         R O T1 T2 SB C,
>>>>     >> >>     }
>>>>     >> >>
>>>>     >> >> This creates consistency, and makes it easy to reason
>>>>     about the temporal/spatial validity of any graph.
>>>>     >> >>
>>>>     >> >> The existing RDF-Star "<<" and ">>" delimiters could be
>>>>     applied to statements of any type to say that a statement was
>>>>     "neutrally asserted", as I think Pat has described it before.
>>>>     Maybe for completeness, and based on something Pat published,
>>>>     other delimiters could be created that would mean
>>>>     "negatively asserted", something like "<!" and "!>" for example.
>>>>     >> >>
>>>>     >> >> The existing RDF-Star "{|" and "|}" delimiters could be
>>>>     applied to statements of any type to add metadata. The example
>>>>     in Section 2 of this email is an example of a complex statement
>>>>     with metadata.
>>>>     >> >>
>>>>     >> >> And I'm not sure, but it seems that nesting statements
>>>>     could be a general solution to contexts, the deepest nested
>>>>     statements would be in the most specific contexts. I haven't
>>>>     examined it properly though.
>>>>     >> >>
>>>>     >> >> If you've made it here thanks for reading! If you need
>>>>     more examples please ask and I'll do my best. I love everything
>>>>     done so far, I just want to bounce around these additional
>>>>     ideas with the hope that they're constructive. Please reply
>>>>     with any feedback at all, good and bad, it's all welcome!
>>>>     >> >>
>>>>     >> >> Regards
>>>>     >> >> Anthony
>>>>     >> > <OpenPGP_0x9D1EDAEEEF98D438.asc>
>>>>     >>
>>>>     > <OpenPGP_0x9D1EDAEEEF98D438.asc>
>>>>
>>>
>>
>

Received on Friday, 21 January 2022 13:31:47 UTC