- From: Pierre-Antoine Champin <pierre-antoine.champin@ercim.eu>
- Date: Thu, 6 Jan 2022 12:32:26 +0100
- To: Niklas Lindström <lindstream@gmail.com>, public-rdf-star@w3.org
- Message-ID: <e6a2809f-9b2a-7af3-9336-9bb106ce7c61@ercim.eu>
Hi Niklas, thanks for a very interesting read! 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? 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)? 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. 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]). 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 >
Attachments
- application/pgp-keys attachment: OpenPGP public key
Received on Thursday, 6 January 2022 11:32:30 UTC