Re: OnAgainOffAgain relations - beyond celeb marriage: Org membership


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 theexisting
>>     <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 captaincyof 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 <http://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?
>>>>

Received on Wednesday, 15 December 2021 06:58:29 UTC