Re: Qualification and identity

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.

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.

> 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".

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
> >

Received on Sunday, 30 January 2022 23:28:20 UTC