- From: Anthony Moretti <anthony.moretti@gmail.com>
- Date: Wed, 15 Dec 2021 17:48:54 +1030
- To: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
- Cc: "public-rdf-star@w3.org" <public-rdf-star@w3.org>
- Message-ID: <CACusdfTRV1hO0Jaxu5j913vfNGy1+_=3AKAzrWKGJbACUx9a4Q@mail.gmail.com>
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?
>>>>>
>>>>>
>>>>>
>>>>
Received on Wednesday, 15 December 2021 07:19:21 UTC