Re: Three ideas

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