Re: Qualification and identity

Hello Thomas,

On Tue, Jan 4, 2022 at 4:05 PM thomas lörtsch <tl@rat.io> wrote:
>
> Hi Niklas,
>
>
> thank you for this very nice post! I agree with a lot of your
> fundamental assumptions and attitudes. Some comments inline.

Thank you for your reply and further thoughts! I'll do my best to
respond. (It took me a while to get around to this, in part due to the
other discussions happening.)

I would like to understand your position better. It appears that we are
in agreement on: 1) people tend to "hold semantics wrong" at times, and
2) the effects of that mustn't be "too" aggravating. This can be hard to
effectively handle of course, and *perhaps* we think differently in
regards to how 3) RDF should provide a means to "show what wrong is",
formally. My personal stance here is that 4) RDF *practise* should cope
with things being "a bit wrong", and that 4.1) named graphs (even with,
perhaps *due to* their lack of formal semantics) is a kind of "wrongness
encapsulation", which makes me less afraid of long-term consequences of
applications and even often ontologies being poorly designed in various
places (as long as it can be "coped with").

I am working to find a way forward with RDF-star, also in relation to
the points I just outlined. This requires assessing what the additional
complexity entails here, and if its value makes the investment
worthwhile. I am growing fairly positive of it in general, although I'd
say most if not all of *my* use cases can be categorized as 4.2)
RDF-star is a means of *structured comments* about course-grained
statements, to provide a kind of "marginalia". I still think a clearer
message and practise is needed for it not only to succeed, but to make
its effect upon RDF practise the intended one (and the *intent* is, from
my point of view, still much under debate here). But I see its
potential, even if viewed as a stopgap towards some unifying solution
(that probably won't emerge anytime soon).


> I’m definitely thinking about the benefits of endurants and the like
> (btw: do you know NdTerms [0])? Their user facing unwieldyness is IMO
> the main problem.

I had not read it, but having skimmed it now I find its core interesting
(NdFluents appear quite like identity qualification). It is rather dense
notation though, and I miss more concrete intent and purpose, and what
is achieved in relation to that (e.g. regarding referential
transparency, and the relationship between NdTerms semantics and
Notation 3 semantics). This gets quite theoretical, and I would like
more application focus ("how to state and query stuff") and practical
effects for interoperability ("sharing data").

While it is quite true that terms are never the same in practise, but
depend on the context they originate from (we all have different
"graphs" in our heads, changing all the time), dealing with that
complexity instead of its reduction is costly (and I hardly think going
from a reduction by applying a *uniform* context makes the facts more
"real"). The renaming seems to yield "one ontology per context" here?
(That appears similar to the `prefix : <#>` pattern sometimes used in
"starting out" examples, before one finds the common terms applicable.)

The "encoding of perspectives" is quite difficult to represent and
compute on. Still, cases in need of *some* kind of variability beyond
the limits imposed by reduction appear often enough to be taken
seriously. This "snag" seems to be a common motivation for many of us
here.

I generally believe that ease of recognition and "ergonomics" of
expressions (especially in their syntactic representations) is crucial
for a technology to be consistently applied. This is IMO where Turtle
(and TriG) has been immensely successful. JSON-LD achieves quite another
aspect here, by bridging the RDF and "general" (web) developer mindset
(where semantics play quite a different role, if any).

I am assessing the effectiveness of RDF-star (through its forms) at the
moment, for the various (apparent or possible) needs of "adorning"
simple expressions I have encountered at work, where complex expressions
cannot be applied due to *practical* constraints (in deployed
applications using vocabularies in need of stability, as opposed
theoretical cases in "laboratory" conditions). Many of these cases boil
down to "recording details after the fact", mainly about provenance and
aspects of specificity in a generalized description, rather than
*actual* qualification.

The motivation is, I believe, that the RDF we have today (reification,
rdf:value and named graphs, on the one hand, and "just vocabulary", on
the other) simply don't address the practical pain points. The solutions
then seem to mainly be "better ontologies and inference for the simpler
forms", or "named graphs could (be improved to somehow) handle this".
And sure, if reasoners were as cheap to apply as dictionary lookups,
we'd be done here. But they're not. I'm experimenting with that [1], but
I don't imagine it catching on anytime soon (and it's mainly designed
for vocabulary interoperability, not (yet at least) within-application
adornment of simple statements).


> RDF-star as defined by the CG report is not what people expect it to
> be and neither what it was and is advertized to be. It is now defined
> as a very specific tool for a very specific task very close to the
> metal of RDF: keeping track of syntactic representations of triples
> during processing (be it reasoning or other transformations). The
> semantic approach chosen by the CG makes good use of the verbosity
> inherent to the embedded triple syntax. So, it’s not a bad design per
> se, but badly positioned and - unlike the widely expected better
> support for reification and property graph style modelling - not
> exactly badly asked for.

I think I see your point. And I certainly agree that RDF-star is *not* a
bad design. I think it is solid work in what it does accomplish.

The debate then appears to what is *needed*: both from what appears to
be lacking today in RDF regarding Named Graph Semantics, on the one
hand, and whether qualification using either N-aries or "identity
indirection" using (the "unpopular") rdf:value (or (thanks
Pierre-Antoine for pointing it out!), prov:specializationOf, which falls
in the category of "just vocabulary").

Now, I do believe that I might not be of the same perspective as you in
regards to property graphs, if I understand you correctly. Is it your
position that the "old school" RDF reification should be formally
relaxed to make two rdf:Statement nodes about the "same" triple be
formally distinct? (No need to answer right away, I'll get back to this
further down.) I am at best agnostic here, as I do believe that one
success of RDF-star seems to lie in solving the uniqueness of a reified
triple.

I'm also fairly agnostic in regards to referential opacity, perhaps
mainly because I don't intrinsically rely on OWL semantics in
applications. I can't quite see how the Superman problem [2] is "real",
as it appears to conflate *opaque identifiers* and *identities*. The
former, identifiers, are when jotted down (as e.g. <superman> or
<clark-kent>), just surface symbols. The *identities* is the real issue,
and that is just the old philosophical puzzle of "Hesperus is
Phosphorus" [3], where *sense* is key (or folly); not a subject of the
abstract propositional or relational algebra of formal semantics.

Given that philosophical puzzles should neither be *solved* in a syntax,
nor should a data model *aggravate* them by enabling users to trample
into them unaware, I find the triple set model of RDF as simple ground
for descriptions, as opposed to say full on contextual, temporal modal
logic, n-tuples or other more complex "substrates". My stance is that
the simple triple set is a sound firmament, and that named graphs
encapsulate semantic errors, so to speak, avoiding a global semantic
bog. Applications are more or less successful at consistently managing
their datasets, and that's nothing we can *solve* through technology
alone. Semantics might always be "held wrong" (many do, as do I, more
than I know of).

> The closest the CG has come to an actual solution for reification and
> statement qualification is an informal :occurrenceOf property. This is
> not what anyone expected the RDF-star effort to deliver. This mismatch
> may very well lead to unintentionally "gaming" RDF-star by those that
> take the syntax for what they expect (or desire) it to mean, and the
> shorthand syntax and the marketing blabla of the CG make this prospect
> even more likely. I fear that will ruin RDF-star in practice (and the
> reputation of RDF semantics in the property graph community).
>
> Your QuID text talks about both faces of RDF-star - the one that the
> semantics in the CG report specifies and the one that it claims to
> also support and that people expect  - as if they were on equal
> footing. They are not, however. The latter is only a syntactic
> possibility but running against the proposed semantics. If anything is
> really gamed here it is the communities - both RDF and property graphs
> - by the RDF-star CG.

I've come to see this more clearly now. Thanks for clarifying that and,
as far as I can grasp it, your perspective on it. As I try to assess
this, I believe I do not so much mind the distance between the, from my
point of view, too lax semantics of PG:s and RDF-star.

I am a bit worried about the complexity of extended core RDF semantics
though, and though the question of whether skolemization of the plain
old rdf:Statement could have been enough has evidently been talked about
[4], I probably need to do the same mental exercise to accept this.

I suppose this is part of what you mean by RDF-star not delivering what
was "promised" to the RDF community?

Granted, there's already a bunch of RDF "cruft" like rdf:value, existing
reification, containers, collections, rdf:langString, the named graph
IRI denotation disconnect, various entailment regimes. It can be argued
that RDF-star adds yet another concept without resolving existing, open
questions.

Thus the cost of implementation (and possible risk of fragmentation) is
a concern. And what it means for RDF 2.0, if anything at all. Far to
often in standardization, there is a kind of fatigue that sets in after
all debates and compromises, that accepts added complexity over a
prolonged pursuit of simplicity. I've been there, I know it mightn't be
helped, and a "stopgap" might be necessary, in the name of pragmatism,
which I duly respect. But it is not to be taken lightly.


> W.r.t. the problem of identification (httpRange-14) the whole semantic
> web is gamed. But it works nonetheless, by and large. There is some
> late-binding strategy as an architectural principle at work that
> navigates troubled semantic waters by leaving things undefined that
> would be too cumbersome, too difficult to define. And that is
> definitely a fully rational approach. Ambiguity is unavoidable in
> practice and has to be handled out-of-band through conventions,
> comments or code. The problem IMO is rather that there is no good
> mechanism to disambiguate identification semantics explicitly when the
> need arises. There’s probaby also too little awareness about this
> tension and too little training in navigating it.

I believe I am in agreement here; albeit I cannot think of what kind of
technique could possibly be applied to make disambiguation of
identification semantics *trustworthy*? I can only think of the
opposite, e.g. to build the "QuID approach" into every identity, saying
that there is no sameness (which there isn't in "reality" perhaps, but
in a finite data space). That would turn the "semantic web" into an
infinitely flexible space (and thus, I fear, formally useless). Anyway,
I think the entire *concept* of identity is ambiguous. So I take solace
in that the puppet theatre of description logic is effectively about
*depicting* reality; and I prefer simple strings (not "strings") and
levers to operate this theatre.

This is also why I'm not particularly fond of "nominalism", I guess; as
it defines some concepts as "unreal" in opposition to others; which are
then purportedly to be taken as "real"? That's a false dichotomy. In
regards to "aspects of reality", when I'm at my best I think in terms of
probabilities and pragmatics, respectively. When I use RDF, I *know*
there are limits (following the rule of least power [5], as opposed to
something loose like S-expressions, contextual grammar, or (horror!)
something flat-out Turing complete). It's a tool for maps, not for
naturalistic painting. Perhaps this stance explains why I'm not
particularly worried about the referential opacity of the
triple-subjects of RDF-star? To me, they are *outside* of the picture.
Marginalia or footnotes. It up to the perceiver to "dive back into the
picture" (once they've been consulted).


> On a practical level some machinery enabling qualification per term on
> demand might just be what’s needed.
>
> In that respect there’s a lot about your QuID proposal that I like but
> also a lot that IMO is still missing, or rather not radical enough.
> Some of your examples could be modeled much more intuitively if you
> applied qualification to the property instead of the object. Why
> qualify the object (or the subject, or both) of a marriage relation
> when it is the relation itself that is only valid during a certain
> period of time? Sure, that requires blank nodes in predicate position.
> If that's all that’s needed, then let's go for it! Or fall back to the
> singleton properties approach.

It is true that qualifying properties is more true to the :marriage
problem. I'll go into that further below.

> I like your thoughts about querying support. A well rounded solution
> might even let queries automagically follow quid:qualifies relations
> to the effect that e.g. a query for <Berkshire> will also return all
> qualified occurrences of <Berkshire>.

Yes, this is what I'm going for in QuID. Of course, in practise, this
may fall under the "variable truth" issue, thus belonging in the can of
worms. Also more below.

> So far complexity is hidden in out-of-band mechanisms, in code and
> comments and conventions. Pulling those ongoings inside the semantic
> web will of course increase complexity of the RDF machinery but I
> think it’s worth it. The tensions between the abstract ideal of the
> global graph and the multitude of practical constraints or between the
> triple as the only harbinger of truth and the need for more elaborate
> constructs are so high that IMO they are unsustainable.

This tension is certainly paramount, I think. It appears to be about the
"naive" simple description logic versus all the overlaps, conflicts and
divergences of the underlying reality (or realities, depending on
perspectives and needs for completeness). I like the "picture" or "map"
analogies to constrain my ambitions, so to speak; these explicitly
acknowledge that *all* means of description have limits.

The method for making effective descriptions then, appears to about
seeking the *simplest* (most reduced) means for a *common* set of needs,
with pragmatic concessions to necessary complexities limited as much as
possible, so that they don't invite complex solutions leading to
accidental complexity hard to get out of.

Of course, a "common set of needs" is key here; that and "pragmatic
concessions" is quite the wiggle room as a principle. This is often
where perspectives, constraints, conflicts of interests and experience
starts to muddy the picture, leaving us with little guidance at all.
Then, first actor wins; "damn the torpedoes" says one, "the consequences
will be dire", says another.


> Of course I’ve got some ideas of my own:
>
> I’m all for generalized RDF. Blank nodes in predicate position would
> allow to qualify properties with data about the relation itself: start
> and end date of a marriage belong here, not to the nodes (Burton and
> Taylor in our running example) and neither to the whole statement.
> Qualifications should always be as targeted as possible.

Certainly, I intentionally "gamed" identity qualification in these
subject and object positions explicitly to keep the predicate untouched
(fully aware of the obvious modelling error), and to stay within what
RDF (and its concrete syntaxes) allows today. And also to make the
"shape" isomorphic to RDF-star annotations, albeit *not* semantically
so. (For better and worse.)

It is indeed possible both to mint new properties to stay within current
RDF, or even to use e.g. Notation 3 and write out a "truly" blank
singleton property. But both such a pattern and the more common
qualified relation pattern are roughly equal in complexity. The "upshot"
of singleton properties is that they preserve the "simple" arc, and make
the predicate the variable factor. But this requires either inference
(if it is declared as a subproperty of the simple ("dumb") predicate),
or querying, both making applications more complex.

I do not think QuID *solves* the general issue of varying precision of
identity either. Like singleton properties, or qualified relations, it
simply represents it. It does so without necessarily increasing the
granularity of the model, if you are ready to accept a coarse-grained
notion of identity for simple applications, and willing to pay the price
of following the indirection.

RDF-star really side-steps it entirely by moving into the "structured
comments". That is simpler, and requires (in principle) nothing for
coarse-grained applications. It keeps the predicate "dumb", and keeps
the picture simple. Invariably so.

I do find "overly" granular models hard to teach, and descriptions using
them hard to maintain cohesively. That said, if the data *is* granular,
moving its details into the margins does present an equally if not more
complex picture over time. ("Always look in the annotations for time
scopes, or units of measurement, relations to affiliations, production,
membership, roles.") There's no free lunch here. Not that I think
RDF-star is promising one, though it may seem to in certain examples. A
casual observer might even believe that "the painting on the far side of
the wall is a window".)


> I like your analogy to rdf:lists. What if we treated _all_ IRI
> references as shortcuts for a blank node with a quid:qualifies
> relation to that IRI and added some sugar to our syntaxes and query
> engines to support this shortcut? That might get us a long way towards
> keeping the simple (simplistic) triple notation, preserving
> triple-based semantics and reasoning mechanisms and yet achieve the
> usability benefit that property graphs provide.

Yes, I'm inclined to believe that this could be valuable. I've long been
wondering if nobody is pursuing to modernize rdf:value for this, at the
*core* of RDF tooling. That could even harmonize literals with actual
*things* (turning their datatypes into rdf:type, and the constituent
parts of their value space being, logically, properties, such as the
year of an xsd:date (I believe e.g. Pat Hayes spoke of similar things a
long time ago [6], if I'm anywhere near interpreting that properly)).

The fact that so many are gearing up to implement RDF-star proves that
people are willing to extend the core of RDF systems. This did fuel my
curiosity as to why this indirection flexibility hasn't been pursued
more. Perhaps the reluctance to do so boils down to one simple thing:
such flexibility costs more, in computational and perhaps cognitive
complexity. Keeping the triples themselves *fully* simple is necessary
for many deployed systems, in spite of the chosen properties proving too
"dumb" (coarse-grained or one-dimensional) for the facts that
occasionally need to be expressed.

So instead of this flexibility, RDF-star annotations simply puts those
details in an *aside*, as pure marginalia.


> But how to annotate whole statements? The RDF-star approach IMO has
> too many downsides. Statement identification per statement id, as for
> example in RDF/XML and RDF standard reification, also isn’t ideal. I’d
> like to treat statements as singleton graphs and consequently
> statement qualification as a special case of graph annotation. I’ve
> never seen a good reason why single and multiple triples should be
> understood and handled as categorically diffferent.
> That would require named graphs to have some formal semantics. Given
> that named graphs are the only grouping device that RDF provides this
> semantics should be as unambitious as possible: the name identifies
> the graph (no disambiguation between use/mention here) and the graph
> is referentially transparent. This semantics also reflects the
> established practice in SPARQL.
> Any other, more involved semantics would have to be declared
> explicitly (e.g. with qualifiers on the graph name).
> A nesting syntax like in N3 (but referentially transparent, and with a
> naming facility added) would be nice.

I agree that there seems to be something missing between quoted triples
and named graphs. Also, as we know, one triple alone isn't always
sufficient to represent a "complex fact". I guess a poignant case is
quoting RDF lists. No model of reification I've seen (apart from named
graphs as "literals") can talk about this with ease:

    <book> bibo:authorList ( <alice> <bob> ) .

nor "structured values" like:

    <book> bf:title [ bf:mainTitle "The Bog of Meaning" ;
                      bf:subtitle "adventures in semantic space" ] .

As you say, allowing for nested graphs *could* solve this.

Still, perhaps annotating or quoting their constituent triples
individually -- and if needed tying those together with links into a
unit (named graphs as sets of statements) -- is simply the price to pay
for doing "nesting" within the same graph at this point. Maybe in
practise it's even enough to annotate the "start" link (to the leading
bnode) of the list and structured value respectively. I could work with
that, just leaving the "dangling node" as an "orphaned" bundle of facts.
Impure, sure, but how pure must this really become?

I am coming around to accept that quoted triples are so linkable to a
source, which may be a named graph; or an rdfg:Graph, I guess, since the
name *cannot* be formally linked as things stand. The JSON-LD hacker in
me simply doesn't care enough, and perhaps worry more about too many
divergent options (as we will expose end users (particularly librarians)
to these notions, one way or another).

A bunch of use cases where dealing with at the National Library of
Sweden are related to provenance, and I am evaluating the effectiveness
of RDF-star annotations for those. Some include linking triples to
versions of documents (also enabling a "blame view" in RDF). Others are
more just "structured comments", and thus could work, semantically, as
just marginalia outside of the assertion itself.

A clear delineation between these seems in order though, since the
pictured can indeed quickly become muddy when combining these use cases.
And regular qualification seems to fall outside of the pattern, apart
from when the model simply doesn't allow for it. One particular case is
for describing e.g. serials, where the (endurant!) entity over time have
a set of sometimes seemingly opposing facts (such as newspapers having
various political views (overlooking the obvious "it's not the paper
itself that holds a political view" objection)).

> The httpRange14 problem lurks everywhere in RDF. We somehow got by so
> far without solving it but I think we should implement a mechanism to
> disambiguate identification semantics on demand, on any level: nodes,
> statements, graphs. That should solve a lot of problems. It could be
> realized as a qualifying property like :identificationSemantics with
> possible values :denotation|:indication (or :use|:mention or
> :documented|:document). That would allow us to easily differentiate
> annotations on statements or graphs (as documents of their own right)
> from annotations on what they refer to, and annotations on documents
> themself (represented by their IRIs) from annotations on the meaning
> they convey. More on the implications on the semantics below.

I agree, that problem is at least ostensibly integral to human
semantics. Of course, it needs to be avoided if possible, through
precise definitions of predicates and in their application. I'm loath to
publish metadata about books at a URI conflated with the book itself and
state that this book/about-the-book thing is licensed under CC0. But in
general, some level of punning is quite necessary for any RDF (or any
description) to work in practise. (This is related to the part in the
QuID article about identities themselves being "useful fictions".)

In this respect, I believe that the more precise this terminology
becomes, the more people will, unwittingly, misuse it. The use/mention
distinction may indeed "seem rather pedantic".

Not that a clarifying mechanism can't be useful. Precisely defined RDF
vocabularies make it easier to do what's intended, and to point out
misapplication if such occurs. Just as long as the limits to precision
are also clear enough to avoid unfounded expectations or needless
disagreements.


> We need more design patterns. A symmetric relation like marriage is
> actually not a very good fit for a directed graph. Good old tables,
> encoded as n-ary relations can do a very good job at describing
> complex objects. However, if we had a solid and sound statement
> annotation facility we could combine both idioms:
> - let the marriage be described in an n-ary relation in all gory
> detail, easily extendable to multiple marriages of the some couple and
> what have you.
> - let ’shortcut' triples describe the essential facts and link them to
> the complete description via a statement annotation.
> Best of both worlds, IMHO. But it would require a way to soundly
> address those shortcutting triples.
> Added benefit for symmetric relations: describe both directions via
> 'shortcut' triples that via qualifiers on the statement as a whole
> 'link back' to the complete description of the marriage as an n-ary
> relation.

Yes, we do need design patterns, that is recurring patterns from vetted
real-world scenarios in deployed applications. Wikidata is one case,
albeit for all its breadth perhaps not the most profound. Vertical
domains tend to have more depth and particularity (such as the UniProt
case, or for that matter the library domain, in its variety of guises).

Do you find RDF-star annotations *basically* sound for this, barring
disagreements about detailed semantics?


> Multisets are only problematic if the statement identifier identifies
> a type. The verbosity of the RDF-star embedded triple plus the need
> for an extra statement to define the occurrence makes this approach
> rather unattractive for statement annotation. We need another
> syntactic device: either statement identifiers or singleton graphs
> (the latter we do of course have already, the former we have in
> RDF/XML - albeit both without standardized semantics).

Just to be clear here, this isn't about *real* multisets as in `<s> :p
<o>, <o>` not being identical to `<s> :p <o>`? Do you agree that those
two snippets represent the same triple?

(In RDF we know they do, I just wonder if the PG notion here differs in
a way that is considered actually valuable in PGs. I saw hints of it in
the "pipe" example of the Amazon Neptune use cases; therefore I wonder
if there is a fundamental difference here.)

The *basic* set notion of the triples themselves is crucial.
Particularly, it is necessary for enabling qualification and
reification. Any "double occurrence" of a statement would have to go
into distinct named graphs (and such occurrences could be further
elaborated upon by describing a quoted triple (using :occurrenceOf)).

Your objection to RDF-star semantics then is strictly about this triple
itself being the subject in RDF-star, as opposed to a "dismantled"
reification? That is, for this:

    _:spo1 a rdf:Statement ;
        rdf:subject <s> ;
        rdf:predicate :p ;
        rdf:object <o> .

to be formally distinct, from:

    _:spo2 a rdf:Statement ;
        rdf:subject <s> ;
        rdf:predicate :p ;
        rdf:object <o> .

(And subsequently that *only* the above, plus an asserted `<s> :p <o> .`
would be enough for annotations, making the separate unstar reification
vocabulary unnecessary?)

Importantly, it appears that uniqueness of the triple as subject is
necessary for annotations (as currently conceived) to work? Otherwise
there would be an inaccessible disconnect between the dismantled,
reified form and the assertion itself.


> Multisets like the marriages between Burton and Taylor however are
> best covered by qualified properties as they actually hinge on the
> relation between the two nodes, not on the statement as a whole:
> :Burton _:p :Taylor .     _:p quid:qualifies :marriedTo;
> :start 1964;         :end 1974 . Another version, with some more
> detail:     _:s _:p _:o .     _:s quid:qualifies :Burton ;
> :firstName :Richard .     _:p quid:qualifies :marriedTo;
> :start 1964;           :end 1974     _:o quid:quaifies :Taylor ;
>   :nickname "Liz" .

I certainly agree that the "married twice" case just isn't a simple
relation. The data doesn't look like that, it would be flat out
misguided to attempt to encode that as two triples with the same
subject, predicated *and* object.

Of course with RDF annotations you could write *in the margins* that it
is too simple and that it "happened twice", "appeared indecisive",
"never really ended" or whatever. But the arc simply wouldn't reflect
that, regardless of annotations. They are at best "hints" for a future
remodeling of the necessary assertions. This is fine, I think, from a
practical perspective. At least if they are presented as such.


> This can rightfully be accused of being decidedly blank node heavy but
> OTOH the traditional ways of modelling complex objects n RDF need a
> lot of blank nodes too and, more importantly, this approach here can
> easily be made more usable by hiding it behind a surface syntax. I’m
> leaning towards statement identifiers, with additional fragment
> identifiers:
>     :Burton :marriedTo :Taylor id_1 .
>     id_1#subject :firstName :Richard .
>     id_1#predicate :start 1964; :end 1973 .
>     id_1#object :nickname "Liz" .
> This preserves the basic relation in an easy to write/read/query
> triple and keeps all refining detail nearby.

Would you consider the following RDF-star annotation as an acceptable
form of the above?

    :Burton :marriedTo :Taylor {|
        :subjectQualified :[ firstName :Richard ] .
        :predicateQualified [ :start 1964; :end 1973 ] .
        :objectQualified [ :nickname "Liz" ] .
      |}.

Or do you wish to be allowed to add an id_2, id_3 and so forth without
needing to "refactor" the annotation into embedded :occurrence nodes?


> I’m not sure that this is all: what about the need to speak about a
> statement or graph as an expression of meaning on its own right (which
> might be different from "adding up" the meaning of all the parts it is
> composed of)? Well, we’re not limited to just two graph naming
> semantics but things might get out of hand…

I think I see where you're going here, as it begins to form concrete use
cases and an attempt to unify named graphs and reification (ideally
within RDF-star, I presume). What would you say would be *key* to change
in, or add to, RDF-star itself, if it is to be finalized as a W3C
Recommendation, with the rest of the named graph semantics left to be
addressed, but in a manner compatible (perhaps even convergent with)
RDF-star?

Because while I do see some further needs for clarification, my
assessment is that RDF-star has value. It is hard to please every
perspective and need, but of course it is also important to avoid
creating divergence where convergence seems possible, even if far off.

And I would like clarity about whether this "marginalia" interpretation
is at odds with any emerging third form of "qualification". And, again,
whether further work on named graphs, soon or later on, might conflict
with practices that might emerge now.

My *hunch* is that if annotations are taken to be *within* the same
graph (but in its margins, conceptually), and quoted statements are
*from* (relatable to) some graph (again, conceptually), there is a
possible path to unification of RDF-star and named graphs, and it could
clear up what annotations apply to. Specifically:

1. Annotation assertions simply pertain to the triple in the current
graph. Any *other* graph where the same statement would appear would
have to be related to from within (with e.g. :occurrence, :source or
:assertedIn), but as the *current* graph is the "scope" of the statement
(where it belongs, just as the regular triples do), there is no need to
qualify that (in fact, it would be pointless if the subject *is* triple
in the current graph).

2. Quoted statements are fragments of some (any) named graph. *If* named
graphs, now or later, become nestable, it could make sense to make these
fragments equivalent to "unary" nested graphs (and the "complex fact"
case above would be two or more fragments in a nested graph). Perhaps
this is reconcilable with Notation 3 semantics as well? This does not
need to happen in RDF-star, as long as it is conceptually compatible
with this future feature.

These conceptualizations are pretty informal and speculative. While I'm
at it, I would like some feedback on my thinking that the triple (and
its annotation triples) are not "free-floating" in the global graph of
facts, but belong in the same "paper", i.e. the current graph.
Entailments, I gather, are produced *outside* of that? That's usually
how I mechanically make sense of entailment, admittedly without regards
to formal definitions. From this point of view (unless it's gibberish),
isn't the entire graph opaque? If so, entailed triples are obviously not
annotated, so the annotated triple is seen as opaque. It's just that
*within* the graph, there is no such opacity.

All the best,
Niklas

[1]: https://github.com/niklasl/ldtvm
[2]: https://www.w3.org/2001/12/attributions/#superman
[3]: https://philosophy.fullerton.edu/faculty/merrill_ring/venusian.aspx
[4]: https://lists.w3.org/Archives/Public/public-rdf-star/2020Oct/0039.html
[5]: https://en.wikipedia.org/wiki/Rule_of_least_power
[6]: https://lists.w3.org/Archives/Public/semantic-web/2009Nov/0040.html

Received on Sunday, 30 January 2022 13:30:02 UTC