Re: Qualification and identity

Hi Niklas,

On 31/01/2022 00:27, Niklas Lindström wrote:
> Hello Pierre-Antoine,
>
> On Thu, Jan 6, 2022 at 12:32 PM Pierre-Antoine Champin
> <pierre-antoine.champin@ercim.eu> wrote:
>> Hi Niklas,
>>
>> thanks for a very interesting read!
> Thank you for taking the time!
>
>> A few comments below:
>>
>> 1) you mention PROV's qualified terms, but I was surprised that you
>> didn't mention PROV's specialization [1]. For me prov:specializationOf
>> and quid:qualifies are very similar. Or did I miss something?
> You did not, it was I who missed that one! I believe I mistook it as
> constrained (to certain artifacts). It certainly seems equivalent to
> quid:qualifies; thanks for pointing it out!
>
> (There's a number of more domain-constrained variants of this notion,
> such as schema:exampleOfWork, bf:expressionOf and
> premis:representationOf. Having this generic variant is certainly
> potential for at least formal interoperability.)
>
>> 2) Your write:
>>
>>   > Therefore, the presence of a quid:qualifies property on any entity
>> immediately conveys its nature as a qualified identity, meaning that it
>> is of the same kind, but of a narrower nature than the thing qualified;
>> and that this narrower nature is conveyed through the other properties
>> if it.
>>
>> but don't you need then to distinguish the properties qualifying the
>> identity (e.g. :earliestYear) from the properties expressing
>> relationships between this qualified identifier and something else (e.g.
>> :partOf)?
> I am not sure that I do? This is part of the fuzziness of
> qualification, for better and worse. How am one to formally separate
> something qualified from its more generic thing? The idea here is that
> one is supposed to do that only by "descriptive extension", if that
> makes sense. The qualified thing is of the same type, but
> conceptualized in a more precise way (such as a person in a period of
> time, or as seen through some peculiarity (e.g. when playing a role or
> taken as playing one)). The properties may be specific to the type at
> hand (such as a :Place) but only applicable for the qualified identity
> (such as an rdfs:label only used during a period of time), particular
> to any quid:QualifiedIdentity (:earliestYear), or fully generic (such
> as many Dublin Core terms). They might also be inapplicable properties
> of course (due to disjointness), but those are the only means to
> possibly formally detect something conflicting.

Here is an example:

     <#me> a schema:Person ;
         schema:givenName "Pierre-Antoine".

     <#me1> a quid:QualifiedIdentity ;
         quid:qualifies <#me> ;
         :earliestDate "2020-09-01"^^xsd:date ;
         :latestDate "2021-12-31"^^xsd:date ;
         schema:worksFor <#ercim>.

     <#me2> a quid:QualifiedIdentity ;
         quid:qualifies <#me1> ;
         :earliestDate "2021-02-01"^^xsd:date ;
         :fellowOf <#w3c>.

(I worked for ERCIM from 2020-09 to 2021-12, and during that time, I was 
an ERCIM W3C fellow starting in 2021-02)

My understanding of quid:qualifies (or prov:specializationOf, for that 
matter), is that the qualified identity inherits the properties of the 
thing it qualifies. So I would like to be able to derive

     <#me1> a schema: Person ;
         schema:givenName "Pierre-Antoine".

     <#me2> a schema: Person ;
         schema:givenName "Pierre-Antoine" ;
         schema:worksFor <#ercim> .

But obviously (?), I wouldn't want to derive

     <#me2> :earliestDate "2020-09-01"^^xsd:date.

I am not entirely sure whether I would like to derive

     <#me2> quid:qualifies <#me>;
         :latestDate "2021-12-31"^^xsd:date .

My point being: if I want to write some rules to automate that kind of 
derivation, these rules will need to distinguish different "kinds" of 
properties (those that can be inherited through quid:qualifies, and 
those that can't).

An alternative could be to attach the "contextual" properties to the 
quid:qualifies edge, using RDF-star:

     <#me> a schema:Person ;
         schema:givenName "Pierre-Antoine".

     <#me1> a quid:QualifiedIdentity ;
        quid:qualifies <#me>  {|
            :earliestDate "2020-09-01"^^xsd:date ;
            :latestDate "2021-12-31"^^xsd:date ;
        |};
        schema:worksFor <#ercim>.

     <#me2> a quid:QualifiedIdentity ;
         quid:qualifies <#me1> {|
             :earliestDate "2021-02-01"^^xsd:date ;
         |};
         :fellowOf <#w3c>.

but I have to think this through longer to decide if I like it or not :)

> Note that I am not fully and generally recommending this practice. It
> is mainly an exercise at this point, albeit drawn from patterns that
> occasionally pop up; especially in libraries where creative works are
> "reified" through their incarnations in e.g. book editions, and where
> variations and personas abound (and where dare I say the lines of
> "real" and "nominal" are sometimes quite blurred).
>
>> 3) I would find the "multiple marriages" more compelling if both Liz
>> Taylor and Richard Burton where qualified. The same goes for the "Alice
>> working for ACME" example.
> Definitely! I actually did consider doing so, but I wanted to keep the
> "isomorphism" of the RDF-star examples from which these were derived.
> Not the least to highlight this important difference, where it is
> fairly evident that qualifying the *relation* makes most sense. Not
> that only qualifying one end is *wrong*, due to the purposely
> "skewable" identity notion of QuID, but it is certainly an unbalanced
> qualification. An RDF-star annotation may appear better here insofar
> as it does take the entire triple into account. The upshot of QuID, I
> believe, is that it avoids the potential gaming of RDF-star
> annotations which I'm troubled by, since QuID does not go into the
> problematic (even erroneous) territory of "conditional truth". Through
> qualification, an entire *identity* is scoped, so every "atomic fact"
> is unaffected, it's the "picture" that becomes more complex.
Very much agreed.
>
>> 4) about the conflation of multiple things behind RDF-star's quoted
>> triples: I fully agree. And yes, this may be solved (to some extent) by
>> some form of punning. But it is IMO cleaner to make an explicit
>> distinction between the different things (triple, statement, fact...)
>> using additional nodes and dedicated predicate (as e.g. in [2]).
> This definitely makes sense. We appear to come into the territory
> where the notion of (any kind of) qualification and RDF-star
> annotations seem to work together. What would you make of this (based
> on an example by Thomas and expressed as an annotation in my recent
> reply to him [1])?
>
>      :Burton :marriedTo :Taylor {|
>          :subjectQualified :[ firstName :Richard ] .
>          :predicateQualified [ :start 1964; :end 1973 ] .
>          :objectQualified [ :nickname "Liz" ] .
>        |}.
> This isn't a pattern I've tried out yet though. I'm currently working
> with the "marginalia" notion (which I much elaborated on in the
> aforementioned reply), where the "triple within the graph" is a simple
> enough concept (and outside of the "picture", as it is a part of its
> composition). In *actual* qualifications, using the above pattern
> would not make things simpler for me, alas, as I think "side-stepping"
> isn't necessary in going from a qualified form (such as an event), to
> a "dumbed-down" relation *without* the details. Only if I wanted to
> "have the cake and eat it too", i.e. *somehow* preserve the data in
> the simpler view, would I use RDF-star annotations for that---by
> putting them "in the magins".

I must confess I don't fully grasp your description above, but it seems 
that you find this pattern overly complicated... in which case I agree. 
I would describe it as "multiplexing" three quid:qualifies relationships 
through a single quoted triple, which does not seem to bring much added 
value. Furthermore, I don't see clearly why :Burton and :Taylor are 
qualified in this example. More precisely, what *specialization* of them 
is meant here? And why is it not made explicit using "restricting" 
properties, such as :earlierYear in the previous examples?

   best

>
> All the best,
> Niklas
>
> [1]: https://lists.w3.org/Archives/Public/public-rdf-star/2022Jan/0101.html

>
>
>>     best
>>
>> [1] https://www.w3.org/TR/prov-dm/#term-specialization

>> [2] https://lists.w3.org/Archives/Public/public-rdf-star/2021Dec/0063.html

>>
>>
>> On 29/12/2021 02:20, Niklas Lindström wrote:
>>> Hello all,
>>>
>>> I sometimes wonder, aren't there any exdurantists [1] on this list (or
>>> people from the twicely fictional Tlön [2], perhaps)?
>>>
>>> Just the other week I wrote up this simple mixed
>>> essay/ontology/critique, spurred by my reading up on RDF-star and all
>>> the surrounding discussions. I called it "QuID - The Qualified
>>> Identity Ontology":
>>>
>>> https://w3id.org/quid/ [3]
>>>
>>> I wasn't fully motivated to bring it up then (it isn't a finished
>>> thought product for one), but given the recent discussion on the list,
>>> I felt that perhaps it might provide some kind of perspective (or
>>> prompt someone to give me constructive feedback). I am not out to
>>> recommend this "QuID" approach over RDF-star annotations (they could
>>> be orthogonal, albeit here poised as contrasts), I just need a way to
>>> clarify on the one hand what I believe is viable regarding
>>> qualification, and on the other what I worry RDF-star is and isn't, to
>>> hopefully gather further insights here.
>>>
>>> The motivation for it was the impression I'm getting that RDF-star
>>> appears to be set up to be somewhat *gamed*. It appears to me (as is
>>> also currently debated) that there may be some conflation of statement
>>> and "asserted but implied event" in use cases here and there, and that
>>> this may be a potential problem going forward (at worst heading
>>> towards an httpRange-14 situation but for every triple...). I wanted
>>> to contrast this with a notion I've had for some time about the
>>> limited nature of the *identities* we use in RDF, and what that
>>> implies in relation to various forms of qualification, including this
>>> "gaming" of RDF-star, specifically its annotation form (which
>>> admittedly I'm drawn to for practical reasons, to the point of wanting
>>> to game it...).
>>>
>>> I also have some concerns that this pursuit of reification (becoming
>>> "triples within triples") might make the simple substrate of triples
>>> in RDF much harder to grasp. But I may be wrong there.
>>>
>>> Perhaps disqualifying me from the fully rational, I am actually fairly
>>> comfortable with ambiguity and broken semantics (though not
>>> necessarily with conflation); and if this "gaming" I am worried about
>>> is considered sound and as intended, I will probably continue to
>>> pursue it in some fashion (I've already gone down that route [4], if
>>> only to avoid inventing something.) It might be that annotations are
>>> "mixed quotations" [5], and the use/mention distinction cannot be
>>> readily applied. That might be a semantic bog in the making of course,
>>> but I suppose any applied semantics eventually strays from the picture
>>> and breaks cohesion. I put my graphs under names and certainly don't
>>> trust the giant global graph of the semantic web to be cohesive (one
>>> stray owl:sameAs and the entire castle comes tumbling down). It's all
>>> just maps, skewed, with varying symbols, granularities and
>>> abstractions. They're not beyond interlinking, even ontology-wise, and
>>> that's workable enough. I'm not a fan of entropy, and endless
>>> complexities (still, alas, I find myself an agent of it, time and
>>> again), but that's the game of nature, and just striving to navigate
>>> it may be enough to get by.
>>>
>>> I do think clarification and harmonization of (or dare I wish, even
>>> unification of) what is happening here on the quoted triple level with
>>> named graphs as a vehicle for triples and provenance would be the most
>>> valuable route towards standardization. And I do miss a clear stance
>>> on qualification (rdf:value has been around long enough without
>>> catching on, so something's amiss). As these are the papers and inks
>>> we're all working with, and we're now about to get a new kind of
>>> colored marker to work with, to clarify how these map making pieces
>>> are to be grasped together would be wise (lest we get lost in the map
>>> making process and forget to navigate our realities).
>>>
>>> Sincerely,
>>> Niklas
>>>
>>> [1]: https://en.wikipedia.org/wiki/Perdurantism

>>> [2]: https://en.wikipedia.org/wiki/Tl%C3%B6n,_Uqbar,_Orbis_Tertius

>>> [3]: Snapshot reference of the article code for future readers of this
>>> list:
>>> https://raw.githubusercontent.com/niklasl/quid/565a15b4263398d9d20b36e2c2af5b204430d6a2/index.html

>>> [4]:
>>> https://github.com/niklasl/ldtvm/blob/master/examples/Spec.md#qualified-relations-as-reifications

>>>
>>> [5]: https://plato.stanford.edu/entries/quotation/#MixeQuot

>>>