- From: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
- Date: Wed, 15 Dec 2021 13:10:03 +0100
- To: Anthony Moretti <anthony.moretti@gmail.com>
- Cc: "public-rdf-star@w3.org" <public-rdf-star@w3.org>
- Message-ID: <bbe52628-87aa-cd24-4aec-6d5436b861dc@ercim.eu>
On 15/12/2021 12:58, Anthony Moretti wrote:
> 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.
yes, it makes sense.
> Examples of subproperties if wanting to be more specific:
> writtenStatementOf, verbalStatementOf, etc.
worms! wooOORMS! XD
(but yes, that also makes sense)
>
> 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 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?
>>>>>>
Attachments
- application/pgp-keys attachment: OpenPGP public key
Received on Wednesday, 15 December 2021 12:10:11 UTC