- From: Anthony Moretti <anthony.moretti@gmail.com>
- Date: Thu, 20 Jan 2022 11:13:03 +1030
- To: Pete Rivett <pete.rivett@agnos.ai>
- Cc: "Patrick J. Hayes" <phayes@ihmc.org>, Fabio Vitali <fabio.vitali@unibo.it>, Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>, "public-rdf-star@w3.org" <public-rdf-star@w3.org>
- Message-ID: <CACusdfTSnRztnQynNuTJE2j=WK+t19kWp04=DyE0LXixdBsgFQ@mail.gmail.com>
Earlier I wrote:
>
> Because the past is different to the future and can be described in a
> Tarskian sense there doesn't need to be a concept of "not existing".
>
Was rushing that, meant to say "stopping existing", was trying to answer
your question about that.
Regards
Anthony
On Thu, Jan 20, 2022 at 10:53 AM Anthony Moretti <anthony.moretti@gmail.com>
wrote:
> Hi Pete
>
> Perfect timing. I just replied to Peter saying that I'm only continuing
> the exploration because there hasn't been strong pushback. This is what the
> discussion needs.
>
> "In RDF-Star, people are creating events by annotating triples with
>> start and end times,"
>> Who are these people? All I've seen is a (poorly chosen IMO) example in
>> the CG document. I don't know of, and find it hard to conceive of,
>> anyone sensibly doing this in a real system since it's just a poor modeling
>> choice that will struggle to meet most use cases where the *event*
>> matters.
>>
>
> Yes, the celebrity marriage example is what started my interest, then more
> examples were given by others in the longer thread, so maybe it's a pattern
> that is going to (naturally in my view) pick up usage, but I could be
> wrong. When you say "event", in my view that's just another way to describe
> a relationship, binary or n-ary, that has an extent in time. If you think
> about it, that's all an event is. Whether events with IDs are more useful
> than events described without them is subjective, and might be influenced
> by the fact that a way to express them without IDs hasn't existed yet, but
> it's very useful to have your view on this because it comes from experience
> that I don't have.
>
> RDF has no way to express "X rdf:createdAt T1" or "X rdf:destroyedAt T2"
>> or "X rdf:hasLifetime [a rdf:Period; start:T1; end:T2]. And good luck with
>> defining what the real world semantics would be - when does a Person or my
>> Car or a City or a Color or a Product start and stop "existing"?
>>
>
> It doesn't need to be expressed because real things wouldn't be the
> subject or object of a statement until after they exist, everything else is
> a fictional concept that exists as a fictional concept, at the very latest,
> from the moment of any statement about them. Because the past is different
> to the future and can be described in a Tarskian sense there doesn't need
> to be a concept of "not existing".
>
> More generally, I think this is a dangerous path: I think RDF, and
>> RDF-star, provide our basic logic primitives that are there to be built
>> upon to build more sophisticated systems for specific needs. OWL is one
>> example.
>> There may well be useful further such sophisticated systems that add
>> different notions of temporality but it would IMO be egregious to force one
>> specific approach into the core primitive layer. Since that's as primitive
>> as it gets and would not allow alternative approaches that may deal
>> differently with temporality or eschew it completely.
>> To draw a parallel, most enterprise data right now is managed in
>> relational databases: people have done pretty well with SQL not
>> having temporal primitives. And it has allowed a relatively small number of
>> people to build temporal databases, using different approaches, using SQL
>> as is.
>> So please let's not try to overburden RDF-star itself with one specific
>> approach.
>>
>
> That's a totally valid argument and where I said to Peter I don't have
> enough experience to say what the right thing to do is. I see optional time
> and space positions as an intuitive way to solve a lot of modeling
> problems, and if there isn't any harm then yeah put them into the most
> primitive layer possible to have the widest possible benefit. But if people
> with more experience, such as yourself, think the possible harms outweigh
> the possible benefits, then that's what I'm keen to know, and if other
> people share the same view please add more comments. Thanks!
>
> Regards
> Anthony
>
> On Thu, Jan 20, 2022 at 9:59 AM Pete Rivett <pete.rivett@agnos.ai> wrote:
>
>> I'd like to strongly challenge the following from Anthony:
>> "In RDF-Star, people are creating events by annotating triples with
>> start and end times,"
>> Who are these people? All I've seen is a (poorly chosen IMO) example in
>> the CG document. I don't know of, and find it hard to conceive of,
>> anyone sensibly doing this in a real system since it's just a poor modeling
>> choice that will struggle to meet most use cases where the *event*
>> matters.
>>
>> Overall I agree with Pat.
>> To add, what was implicit in his response, RDF does not even have, and
>> you have not proposed, Anthony, the notion of *existence* in RDF when
>> you write "Things can't be in a relationship if they don't exist yet". RDF
>> has no way to express "X rdf:createdAt T1" or "X rdf:destroyedAt T2" or "X
>> rdf:hasLifetime [a rdf:Period; start:T1; end:T2]. And good luck with
>> defining what the real world semantics would be - when does a Person or my
>> Car or a City or a Color or a Product start and stop "existing"?
>>
>> More generally, I think this is a dangerous path: I think RDF, and
>> RDF-star, provide our basic logic primitives that are there to be built
>> upon to build more sophisticated systems for specific needs. OWL is one
>> example.
>> There may well be useful further such sophisticated systems that add
>> different notions of temporality but it would IMO be egregious to force one
>> specific approach into the core primitive layer. Since that's as primitive
>> as it gets and would not allow alternative approaches that may deal
>> differently with temporality or eschew it completely.
>> To draw a parallel, most enterprise data right now is managed in
>> relational databases: people have done pretty well with SQL not
>> having temporal primitives. And it has allowed a relatively small number of
>> people to build temporal databases, using different approaches, using SQL
>> as is.
>> So please let's not try to overburden RDF-star itself with one specific
>> approach.
>>
>> Regards
>> Pete
>>
>>
>> On Wed, 19 Jan 2022 at 02:59, 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. Therefore even that
>>> relationship has an extent in time."
>>>
>>> On the Bette Davis example, maybe you can clarify something for me. Do
>>> Tarskian truth conditions apply in RDF? Sincere question because I've
>>> assumed that recently, but I don't know for sure. '"P" is true if, and only
>>> if, P'. Doesn't that imply bounds for temporal validity?
>>>
>>> If I have this triple:
>>>
>>> :JoeBiden :presidentOf :UnitedStates
>>>
>>> Isn't that true only for a period of time? Are we meant to avoid saying
>>> things like that? 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. If I'm
>>> meant to timestamp my graph, isn't that the same thing as saying it has a
>>> temporal validity?
>>>
>>> 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, 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 and it looks like an ongoing
>>> debate between tensed and tenseless theories of time, and some people
>>> arguing that both are valid. If that's so, does it hurt to add
>>> *optional* time and space positions like I'm suggesting? 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
>>>> <https://en.wikipedia.org/wiki/Of_Human_Bondage_(1934_film)>* (1934)
>>>> although, contentiously, she was not among the three nominees for the Academy
>>>> Award for Best Actress
>>>> <https://en.wikipedia.org/wiki/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 Thursday, 20 January 2022 00:43:37 UTC