Re: OnAgainOffAgain relations - beyond celeb marriage: Org membership

One last stab. Could it be as simple as "Triples and statements of triples"?

_:a :statementOf << :s :p :o >> ;
    :in <file1.ttl> ;
    dct:creator :alice.
_:b :statementOf << :s :p :o >> ;
    :in <file2.ttl> ;
    dct:creator :bob.

It matches the RDF reification vocabulary
<https://www.w3.org/TR/rdf11-mt/#reification> in my opinion. Examples of
subproperties if wanting to be more specific: writtenStatementOf,
verbalStatementOf, etc.

Regards
Anthony


On Wed, Dec 15, 2021 at 7:42 PM Pierre-Antoine Champin <
pierre-antoine.champin@ercim.eu> wrote:

> Hi Anthony,
>
> I am not a big fan about "refersTo", and actually I am having second
> thoughts about "mentions" as well, at least in the use-case addressed by
> example 8 [1] in the CG report. The reason is that "mention" (and, to some
> extent, "reference") points to the use-mention distinction [2]. However,
> the intended meaning of the example was that the triple was actually *used*
> in file1.ttl and file2.ttl, not merely mentioned...
>
> I guess this means that we would probably need two distinct referentially
> opaque properties: useOf and mentionOf. And here's another worm out of the
> can...
>
>   pa
>
> [1]
> https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#occurrences-example
> [2] https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction
> On 15/12/2021 08:18, Anthony Moretti wrote:
>
> I had one more thought actually, I think I can take it to its logical
> conclusion. Perhaps the pair should be:
>
>     occurrenceOf (referentially transparent)
>     refersTo (referentially opaque)
>
> The domain of the second would be References, which themselves can be
> referred to, and so on.
>
> References refer to things, and the relevant section of the report changes
> from “Triples and occurrences” to “Triples and references to triples”.
>
> In any case the point is to clear the way for the use of “occurrenceOf” in
> a referentially transparent way rather than the way it’s used now.
>
> And yes, sorry, side message with Pat.
>
> Regards
> Anthony
>
> On Wed, Dec 15, 2021 at 5:28 PM Pierre-Antoine Champin <
> pierre-antoine.champin@ercim.eu> wrote:
>
>>
>> On 15/12/2021 05:45, Anthony Moretti wrote:
>>
>> Note that the `:occurenceOf` predicate in the CG report is just an
>>> *example*, it has no "official" standing in the CG report. Yes, I avoided
>>> that term in order to avoid confusion with the discussion in the report,
>>> but I do not consider any term as definitely taken. "occurrence" vs.
>>> "literalOccurrence" would be fine by me, I guess.
>>>
>>> Note however that we have tried, in the RDF-star group, to coin a
>>> general vocabulary for occurrences... but we failed to reach consensus
>>> after a long discussion, and decided to defer that to the future working
>>> group. This is a nasty can of worms, with a lot of subtle distinctions.
>>>
>>
>> If I've found the right discussions you're right about it being a can of
>> worms (169 <https://github.com/w3c/rdf-star/issues/169>, 170
>> <https://github.com/w3c/rdf-star/issues/170>, 209
>> <https://github.com/w3c/rdf-star/pull/209> etc). I read through them and
>> still think that "occurrenceOf" is preferable to "realizationOf". After
>> some thought, and also heeding Pat's advice about avoiding the use of
>> "literal",
>>
>> did I miss some message in the thread? Or are you referring to another
>> discussion with Pat?
>>
>> maybe the relations of concern could be:
>>
>>     occurrenceOf (referentially transparent)
>>     mentionOf (referentially opaque)
>>
>> I like that.
>>
>>
>> In the dictionary,  a "mention" is "a reference to someone or something".
>> Every time I talk about a triple, whether in writing or speech, can be
>> described as a mention of that triple.
>>
>> So my proposal in this thread is something more targeted: a property
>>> whose domain is restricted a given Event class (although, as Peter Rivett
>>> poinrted out, schema:Event is maybe not the most appropriate one).
>>>
>>
>> There has been lots of discussion
>> <https://lists.w3.org/Archives/Public/public-schemaorg/2018Jun/0013.html>
>> (that I've been a part of) where people would like to broaden the scope of
>> schema:Event to include such things as historical events and notable time
>> periods. If schema:Event were to use the dictionary definition in its
>> description ("a thing that happens or takes place, especially one of
>> importance") then it might solve those problems and also be the domain for
>> "occurrenceOf".
>>
>> Good to know, thanks for the pointer.
>>
>>
>> Regards
>> Anthony
>>
>>
>> On Wed, Dec 15, 2021 at 12:34 AM Pierre-Antoine Champin <
>> pierre-antoine.champin@ercim.eu> wrote:
>>
>>>
>>> On 14/12/2021 14:41, Anthony Moretti wrote:
>>>
>>> Exactly. What I like about the "realization" pattern (or any similar
>>>> pattern involving quoted triples) is that it keeps a link between the
>>>> complex construct (the event) and the simple triple (asserted or not).
>>>>
>>>>   pa
>>>>
>>>
>>> It's a good solution that preserves all the information.
>>>
>>> In place of "realizationOf" I'd like to suggest renaming it to
>>> "occurrenceOf". If we're discussing reoccurring relationships then each
>>> Event is an occurrence of that relationship.
>>>
>>> As a follow-on I'd also suggest renaming the existing
>>> <https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#occurrences> "occurrenceOf"
>>> relation to "literalOccurrenceOf" (and possibly renaming that section of
>>> the report to "Triples and literal occurrences of triples").
>>>
>>> Note that the `:occurenceOf` predicate in the CG report is just an
>>> *example*, it has no "official" standing in the CG report. Yes, I avoided
>>> that term in order to avoid confusion with the discussion in the report,
>>> but I do not consider any term as definitely taken. "occurrence" vs.
>>> "literalOccurrence" would be fine by me, I guess.
>>>
>>> Note however that we have tried, in the RDF-star group, to coin a
>>> general vocabulary for occurrences... but we failed to reach consensus
>>> after a long discussion, and decided to defer that to the future working
>>> group. This is a nasty can of worms, with a lot of subtle distinctions.
>>> So my proposal in this thread is something more targeted: a property
>>> whose domain is restricted a given Event class (although, as Peter Rivett
>>> poinrted out, schema:Event is maybe not the most appropriate one).
>>>
>>>
>>> Regards
>>> Anthony
>>>
>>>
>>> On Tue, Dec 14, 2021 at 6:45 PM Pierre-Antoine Champin <
>>> pierre-antoine.champin@ercim.eu> wrote:
>>>
>>>>
>>>> On 11/12/2021 05:33, Anthony Moretti wrote:
>>>>
>>>> Idea:
>>>>>
>>>>> define a schema:realizationOf property, whose domain is schema:Event
>>>>> and range is rdf-star:Triple (with an inverse property schema:realization).
>>>>> The above could be expressed in JSON-LD-star [1] as follows:
>>>>>
>>>>> {
>>>>>     "@context": "https://schema.org/" <https://schema.org/>,
>>>>>     "@type": "Event",
>>>>>     "realizationOf": { "@id": {
>>>>>         "@id": "#bowls_club",
>>>>>         "captain": "#bob"
>>>>>     }},
>>>>>     "startDate": "01-01-2019",
>>>>>     "endDate": "31-12-2019"
>>>>> }
>>>>>
>>>> That works. Although when stating this I think the start and end dates
>>>> should also be in the RDF-star triple. If the dates aren't there then the
>>>> event is adding information to the triple, whereas I think the intention of
>>>> "realization of" is to show a one-to-one mapping, is that right?
>>>>
>>>> no, see below
>>>>
>>>> If the intention isn't a one-to-one mapping then it's sort of saying
>>>> "instance of", where the only thing differentiating instances is the time
>>>> period, which implies that all standard RDF triples without start and end
>>>> times are implicit *types* of events (also makes sense to me).
>>>>
>>>> yes, this is the idea behind my examples.
>>>>
>>>> Note that, by design, RDF-star does not support the one-to-one mapping,
>>>> because quoted triples are (roughly) like IRIs or literals: they represent
>>>> the *same thing* everywhere they appear. This is discussed in the CG report
>>>> [1].
>>>>
>>>>
>>>> [
>>>>>     a :TenuredOfficeEvent ;
>>>>>     schema:name "Presidency of the United States"@en ;
>>>>>     :hasTermStartYear "1885"^^xsd:gYear ;
>>>>>     :hasTermEndYear "1889"^^xsd:gYear ;
>>>>>     :hasOfficer dbpedia:Grover_Cleveland
>>>>> ] schema:author [
>>>>>                       a schema:Person;
>>>>>                       schema:worksFor <
>>>>> https://www.whitehouse.gov/#this>
>>>>>                   ] ;
>>>>>    schema:publisher <https://www.whitehouse.gov/#this>  .
>>>>>
>>>>> [
>>>>>     a :TenuredOfficeEvent ;
>>>>>     schema:name "Presidency of the United States"@en ;
>>>>>     :hasTermStartYear "1893"^^xsd:gYear ;
>>>>>     :hasTermEndYear "1897"^^xsd:gYear ;
>>>>>     :hasOfficer dbpedia:Grover_Cleveland
>>>>> ] schema:author [
>>>>>                       a schema:Person;
>>>>>                       schema:worksFor <
>>>>> https://www.whitehouse.gov/#this>
>>>>>                   ] ;
>>>>>    schema:publisher <https://www.whitehouse.gov/#this>  .
>>>>>
>>>>> ## Turtle End ##
>>>>>
>>>>> Key point:
>>>>>
>>>>> No reification required, courtesy of RDF's fundamental essence :)
>>>>>
>>>>> Kingsley
>>>>
>>>>
>>>> That works, although it's less flexible because it interleaves
>>>> concepts. For it to be fully understood a reasoner has to understand
>>>> "Presidency of the United States" rather than simpler concepts that can be
>>>> reused like "is President of" and "United States". Composition over
>>>> inheritance
>>>> <https://en.wikipedia.org/wiki/Composition_over_inheritance> could
>>>> probably make the design simpler, but yeah it works for sure too.
>>>>
>>>> Exactly. What I like about the "realization" pattern (or any similar
>>>> pattern involving quoted triples) is that it keeps a link between the
>>>> complex construct (the event) and the simple triple (asserted or not).
>>>>
>>>>   pa
>>>>
>>>> [1]
>>>> https://w3c.github.io/rdf-star/cg-spec/editors_draft.html#occurrences
>>>>
>>>>
>>>> Personally, modeling would be much cleaner and more complete if all
>>>> statements could have start and end time positions, and ideally a location
>>>> position, then every statement has the _option_ of being scoped in space
>>>> and time. The modeling of recurring events then falls out of that and
>>>> people could either do it Kingsley's way with events or just use statements
>>>> with start and end times, whichever they prefer.
>>>>
>>>>
>>>>
>>>> Regards
>>>> Anthony
>>>>
>>>>
>>>> On Sat, Dec 11, 2021 at 3:43 AM Pierre-Antoine Champin <
>>>> pierre-antoine.champin@ercim.eu> wrote:
>>>>
>>>>>
>>>>> On 10/12/2021 04:05, Anthony Moretti wrote:
>>>>>
>>>>> Agreeing with Dan here, you could argue that any instance of
>>>>> schema:Event is also an example.
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> Taking Simon's example:
>>>>> Bob - is captain of - Bowls Club - Jan 1, 2019–Dec 31, 2019
>>>>> Bob - is captain of - Bowls Club - Jan 1, 2020–Dec 31, 2020
>>>>>
>>>>> Seems equivalent to:
>>>>>
>>>>> schema:Event
>>>>> Bob's captaincy of Bowls Club 2019
>>>>> startTime: Jan 1, 2019
>>>>> endTime: Dec 31, 2019
>>>>>
>>>>> schema:Event
>>>>> Bob's captaincy of Bowls Club 2020
>>>>> startTime: Jan 1, 2020
>>>>> endTime: Dec 31, 2020
>>>>>
>>>>> Idea:
>>>>>
>>>>> define a schema:realizationOf property, whose domain is schema:Event
>>>>> and range is rdf-star:Triple (with an inverse property schema:realization).
>>>>> The above could be expressed in JSON-LD-star [1] as follows:
>>>>>
>>>>> {
>>>>>     "@context": "https://schema.org/" <https://schema.org/>,
>>>>>     "@type": "Event",
>>>>>     "realizationOf": { "@id": {
>>>>>         "@id": "#bowls_club",
>>>>>         "captain": "#bob"
>>>>>     }},
>>>>>     "startDate": "01-01-2019",
>>>>>     "endDate": "31-12-2019"
>>>>> }
>>>>>
>>>>> (assuming that "realization" and "captain" are part of the schema.org
>>>>> context)
>>>>>
>>>>> The annotation syntax could also be used, if bob was *currently*
>>>>> captain of the club:
>>>>>
>>>>> {
>>>>>     "@context": "https://schema.org/" <https://schema.org/>,
>>>>>     "@id": "#bowls_club",
>>>>>     "captain": {
>>>>>         "@id": "#bob",
>>>>>         "@annotation": {
>>>>>             "realization": {
>>>>>                 "@type": "Event",
>>>>>                 "startDate": "01-01-2021",
>>>>>                 "endDate": "31-12-2021"
>>>>>             }
>>>>>         }
>>>>>     }
>>>>> }
>>>>>
>>>>>   pa
>>>>>
>>>>> [1] https://json-ld.github.io/json-ld-star/
>>>>>
>>>>>
>>>>> PS: in case anyone is wondering, the Turtle-star corresponding to the
>>>>> above JSON-LD-star would be
>>>>>
>>>>> [] a s:Event ;
>>>>>     s:realizationOf << <#bowls_club> s:captain <#bob> >> ;
>>>>>     s:startDate "01-01-2019"^^s:Date ;
>>>>>     s:endDate "31-12-2019"^^s:Date.
>>>>>
>>>>> and
>>>>>
>>>>> <#bowls_club> s:captain <#bob> {|
>>>>>     s:realization [
>>>>>         a s:Event ;
>>>>>         s:startDate "01-01-2019"^^s:Date ;
>>>>>         s:endDate "31-12-2019"^^s:Date
>>>>>     ]
>>>>> |}.
>>>>>
>>>>>
>>>>> It seems natural to me that every triple should have start and end
>>>>> time positions and possibly also a location position. The above examples
>>>>> seem to me like different ways of saying the same thing, albeit the first
>>>>> has more structure. You could argue that schema:Event is just a convenience
>>>>> type for statements with temporal data.
>>>>>
>>>>> YAGO knowledge base is a good example:
>>>>> https://www.sciencedirect.com/science/article/pii/S0004370212000719
>>>>>
>>>>> Regards
>>>>> Anthony
>>>>>
>>>>>
>>>>> On Fri, Dec 10, 2021 at 8:20 AM Cox, Simon (L&W, Clayton) <
>>>>> Simon.Cox@csiro.au> wrote:
>>>>>
>>>>>> Captain of the bowls club is another example.
>>>>>>
>>>>>> (I was in one of these the other day admiring the wooden honour
>>>>>> boards – the same names come up repeatedly but not necessary sequentially.)
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Dan Brickley <danbri@google.com>
>>>>>> *Sent:* Thursday, 9 December, 2021 22:57
>>>>>> *To:* public-rdf-star@w3.org
>>>>>> *Subject:* OnAgainOffAgain relations - beyond celeb marriage: Org
>>>>>> membership
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The celebrity re-marriage example is interesting and real, but may
>>>>>> look a bit artificial or cornercase. A similarly structured situation is
>>>>>> much more common - membership of organizations.
>>>>>>
>>>>>>
>>>>>>
>>>>>> For example one organization being a member of another.
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://www.wikidata.org/wiki/Q51698517 is the International Fact
>>>>>> Checking Network (IFCN). It has a notion of membership grounded in review
>>>>>> of members w.r.t. their official principles.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Verified signatories are e.g. https://www.wikidata.org/wiki/Q30325238
>>>>>> (Full Fact). There are some organizations such as Snopes (
>>>>>> https://www.wikidata.org/wiki/Q2287154) who were once members
>>>>>> (verified signatories) but who are not currently.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Wikidata uses annotations on a
>>>>>> https://www.wikidata.org/wiki/Property:P463 edge between IFCN and
>>>>>> Snopes to give start/end times (
>>>>>>
>>>>>> 15 April 2017, 5 June 2019). It also points to evidence/source
>>>>>> document.
>>>>>>
>>>>>>
>>>>>>
>>>>>> As far as I know Snopes have only been members once, but if they were
>>>>>> to rejoin it seems Wikidata could accomodate the task of representing this.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Until I learn a better name for it that isn't too grandiose, I am
>>>>>> calling these "on again, off again" relationships, in honour of the
>>>>>> celebrity marriage/divorce usecase.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>> p.s. another example, not quite notable enough for Wikidata to record:
>>>>>>
>>>>>> I (https://www.wikidata.org/entity/Q56641640) have twice been a
>>>>>> member of https://www.wikidata.org/wiki/Q7552326 (AISB - Society for
>>>>>> the Study of Artificial Intelligence and Simulation of Behaviour).  But
>>>>>> then I have multiple times lived in the U.K., or been in various
>>>>>> restaurants; how do we scope RDF-Star's applicability? Which of these are
>>>>>> reasonable places it could be used for time-scoped relationships?
>>>>>>
>>>>>>
>>>>>>
>>>>>