Re: Three ideas

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