- From: thomas lörtsch <tl@rat.io>
- Date: Tue, 8 Feb 2022 02:12:42 +0100
- To: Niklas Lindström <lindstream@gmail.com>
- Cc: public-rdf-star@w3.org
Hi Niklas,
I’m concentrating on some of the more concrete issues to let this response reach you rather sooner than later. Hope that helps...
> Am 30.01.2022 um 14:29 schrieb Niklas Lindström <lindstream@gmail.com>:
>
> 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).
RDFD*/-star changed over time. It always promoted provenance as a use case although it never quite took into account that provenance is more related to occurrences than types. It positioned itself as being able to bridge the gap between Property Graphs and RDF when that became a thing but it never cared much to actually make good on that promise. The proposed semantics requires the PG use case to go through the trouble of defining TEPs per graph and narrows down the focus of provenance to a very tight form of quotation, all that for the sake of an IMO really niche use case: close to the metal versioning, explainable Ai, also what you mention further below as tracking who dunnit - all venerable uses for sure, but decidedly not about facilitating integration and much more easily implementable with e.g. an RDF literal datatype.
OTOH, by defining the embedded triple as referentially opaque, the proposed semantics makes the link between a statement and its annotations unnecessarily brittle and semantically weak and even vague. Very few use cases require an annotation to the exact syntactic representation of a statement. But an annotation on an embedded triple annotates only that syntactic representation. Now, what do I make of an RDF-star annotation that I gather from an unknown source: can I be sure that they really meant only those exact words or should I assume that they assumed that they are annotating the meaning of what they annotated?
:Alice ex:buys :Car .
<<:Alice ex:buys :Car >> :on :Monday .
All the other questions discussed so far - about temporal aspects and if the annotation annotates the property or the whole statement etc - aside: this annotation doesn’t annotate the fact that Alice bought a car. It annotates that Alice as referred to by the URI :Alice (not by her SSN, not by her eMail-address, not by the lowercase :alice) did something referred to by the property :buys from the ex vocabulary (not :purchased from the yz vocabulary) to something referred to as :Car (not :Auto or :Automobile, not :Vehicle, not the Wikipedia/DBpedia/Wordnet/Schema.org equivalent). The embedded triple doesn’t talk about the full meaning of the statement that the embedded triple mimics. In all but very few cases that is NOT what we want and in all cases it is not what RDF does today. But, as the distinction is rather subtle, as the syntax lures one into thinking that everything is alright and normal, as everything else (like defining a proper "transparency-enabled" version of :on anew for each graph in which it is to be used) is much more cumbersome, this is what will happen: annotations will regularily mean the statement as meant while according to the proposed semantics they actually only annotate the statement as stated.
This IMO is the main problem with the proposed semantics and the proposal as a whole. The editors suggest that TEP (transparency enabled properties) is a workable solution, and I strongly disagree. Pierre-Antoine in his latest blog post himself gamed these semantics because he don’t want to bother (and chase away) potential users with such idiosyncracy. This semantics has no chance to succeed in practice because it is quite unreasonable. So, why pursue it?
Other problems like the focus on types when use cases predominantly point to occurrences would need other defaults and in general a more serious treatment where the CG report is mostly concerend with advertizing the alleged simplicity of RDF-star. Multisets and occurrences in general are much less of a problem if the address is not a type but a proper identifier, an approach rather orthogonal to and less verbose than the embedded triple. But those problems IMO are all secondary. The semantics really bothers me the most as IMO it is leaky and has the potential to creep like a virus into the whole of RDF: if annotations and Property Graph style qualifications via RDF-star become ubiquituous they will influence how we read the statements so annotated. That application-centric reading gets in conflict with co-denotation, with reasoning, with the very basic assumptions underlying the Semantic Web and essential to its capacity as a data integration platform.
>> 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").
TBH I haven’t managed to fully understand it yet… but my hope is that this provides a semantically sound basis in which optimizations can be grounded, making it easier to state and query stuff while being confident that it is sound and therefore can be shared.
> 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.
Not sure about that. I believe that the mental models range from "refining a statement with further detail intrinsic to it" to "making a statement about another statement without changing that other statement at all". That range of mental models can lead to very different design choices and interpretations of designs. But that range is also fluid: the source of a statement can determine how it has to be read, words change meaning depending on who utters them, what is housekeeping data in one context may become critically meaningful in another. So I think we have to strive for a formalism that is agnostic to such differences and covers the whole range of mental models equally well - from detail to context, from intrinsic to extrinsic -, facilitating late disambiguation when using the data instead of early on when authoring it. It should depend on the information desire when querying and reasoning how some annotation is understood and operationalized. Until that point the formalism should be as neutral as possible.
> 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).
If only they knew what they are missing out on ;-)
> 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.
Not surprising given your area of work. But how important is co-denotation for you? Could you do without that?
And how would you fare with standard reification? How many annotations per annotated statement do you expect? I recently read an old paper by Welty et al where they claimed to have about 20 to 30 annotating triples per reified triple, and therefore the overhead of the standard reification quadlet was a non-issue for them.
I was always discontent with how unwieldy a graph quickly becomes when the subject area gets more complex, and I find the Property Graph approach to prioritize information into primary relations and secondary attributes very attractive (although too unprincipled). So my thinking is definitely more concerned with the qualifiction side of things.
> 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.
IMO this has nothing to do with reasoners at all. If Turtle did provide an id attribute like RDF/XML does - and maybe SPARQL also a shortcut to query for reified triples in one line instead of three - I bet we wouldn’t have this discussion at all.
> I'm experimenting with that [1],
I watched the talk at https://www.youtube.com/watch?v=A_1BIDAlbeI - very nice! Favorite cite: "More like linkable layers of worlds". You shouldn’t excuse yourself for using only parts of OWL, and OWL Full at that. I’d say that that is a perfectly valid and indeed very reasonable approach. And good to hear that it seems to scale well! Did you get any uptake from others since that talk in 2019?
Also, now exposing my ignorance: why is it that reasoners can’t be told to only go for certain properties? Is that an oversight, a missing feature that could be easily added if the demand was realized, or is there something more going on?
> 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.
Well, okay, I fear I was trying t be polite when maybe I shouldn’t (but it’s seldom enough that I try): making good use of the embedded triple's verbosity is of course a good thing but that’s practically all I have to say in favor of RDF-star. And although some of the criticisms I voiced over the last year were unfounded or exxagerated, in principle I still think that there are better solutions for every aspect RDF-star tries to cover: RDF literals for close to the metal use cases, proper identifiers (for statements and/or graphs) for use cases that talk about occurrences, and nested graphs in a shiny distant future. But RDF-star really not so much in any of those cases, and certainly not at the center of it all.
> 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").
It takes a bit more than just vocabulary to be really useful in practice: ideally such a property would be supported in all interface layers, e.g. by automatically rendering it instead of the blank node it qualifies, by being shown as a result in a query that didn’t explicitly add the qualification pattern etc.
> 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?
I think that it was the RDF semantics, although informally, says, not a relaxation. In
:X rdf:subject :s; rdf:predicate :p; rdf:object :o; a rdf:Statement.
:Y rdf:subject :s; rdf:predicate :p; rdf:object :o; a rdf:Statement.
:X and :Y are two distinct entities. :X might be uttered by :Alice, while :Y is ascribed to :Bob. So :X and :Y represent two different speech acts, involving the same utterance. That should be a fairly standard scenario in bibliography.
Maybe speech act is not the right term here, as Pat Hayes seems to associate them with referential opacity, but hopefully it’s close enough. Otherwise just go with "occurrence".
> (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 not sure I understand. Do you say we need another type, e.g. a rdf:StatementType, to refer to all statements of the same type?
I was quite violently arguing for honring the distinction between type and occurrence (see for example https://github.com/w3c/rdf-star/issues/169) but I’m not so sure anymore that I was right. Normally I’m all in favor for late binding semantics. As semantics is such a beast it’s in general better to sneak around it. The class/instance distinction is no exception as e.g. punning in OWL 2 shows. Annotating an embedded triple with some (albeit ill-defined) provenance as Pierre-Antoine did in his recent blog post (https://www.w3.org/community/rdf-dev/2022/01/26/provenance-in-rdf-star/)
<< :employee38 :jobTitle "Assistant Designer" >>
:accordingTo :employee22 .
says - as the embedded triple is a type - the type occurred according to employee 22. So the fact that there was an occurrence is evident but isn’t made explicit. A second occurrence of the same form like
<< :employee38 :jobTitle "Assistant Designer" >>
:accordingTo :employee22, :employee38.
is still unproblematic. But when the annotations get more complex (or when we don’t game the semantics and go with Antoine Zimmermanns more elaborate alternative), we need intermediate nodes (blank or not blank) and it becomes obvious that we are talking about occurrences.
<< :employee38 :jobTitle "Assistant Designer" >>
:accordingTo
[ rdf:value :employee22; :confidence 0.2] ,
[ rdf:value :employee38; :confidence 0.8] .
or
<< :employee38 :jobTitle "Assistant Designer" >>
:hasClaim <#c1>, <#c2>.
<#c1> :claimer :employee22; :claimConfidence 0.2 .
<#c2> :claimer :employee38; :claimConfidence 0.8 .
as Pierre-Antoine puts it. One reason that I prefer proper identifiers baked into the syntax (like in RDF/XML, also like the names of named graphs and the id’s of standard reification) is that they do not allow that shortcut implicit in both examples above. Modelling with proper idnetifiers is therefore more uniform, more predictable and easier to query. It is still concise as it avoids the embedded triple’s verbosity.
> I'm also fairly agnostic in regards to referential opacity, perhaps
> mainly because I don't intrinsically rely on OWL semantics in
> applications.
I already asked that above: don’t you use co-denotation? It seems to me that a lot (or all) you do in [1] breaks when referentially opaque embedded triples provide the link betwen a statement and its annotations.
> 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).
Seems that we agree here.
>> 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]
Oh, *I* wrote *that*? Well, IIRC I wasn’t fully aware of the ramifications of referential opacity back then. I’m not sure that’s what Pierre-Antoine was referring to with 'internal structure' but I don’t want to re-read that whole thread. Brave you, that you did!
> , 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?
What was promised was syntactic sugar for RDF reification, thereby easing the way for PG-style statement annotation in RDF. The CG report is now at least very clear that that is not what it delivers.
> 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.
Instead adding new ones, and using up two bracket-syntaxes on the way.
> 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.
I interpret the broad support for RDF-star as a sign that a syntactic alternative to RDF standard reification is badly desired. That support started well before the proposed semantics was introduced and I can’t remember that any of the implementors came forward on this mailinglist to actually support the proposed semantics - except Andy. There were reactions to the effect of "we trust you to do the right thing (although our customers are asking for reasoning support, you know)" but no one saying "yes, THIS is how we want it". It feels more like the support is still there despite the semantics and is rather a sign of not taking it serious - not a good sign to be sure but rather a recipe for further semantic desaster.
If we were weighing proper identifiers against a referentially transparent version of RDF-star I guess I’d be with you: RDF* gained momentum as it came in teh right moment to fill the void behind the RDF 1.1 Named Graph standardization desaster and the unfullfilled promise of Singleton Properties. This is the dynamics of history and there’s only so much we can do about it. But for the reasons given above, referentially opaque embedded triples IMO pose a real danger. They would only be tolerable if a much easier syntax for referentially transparent reification would be introduced in parallel, so that the bulk of use cases could be gently nudged to do what’s right for everybody. If that much easier syntax should best materialize as proper identifiers or as the RDF-star shortcut syntax or as nested named graphs would be another discussion. And if the referentially opaque embedded triple couldn’t easily be replaced by RDF literals is yet a further discussion - but I start to repeat myself.
>> 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*?
Let’s assume a simple :identificationSemantics qualifier with possible values :Denotation and :Indication (or :Fact and :Statement, or :Interpretation and :Syntax etc). That would be enough to express the author's intent. Not trustworthy? Why not?
> 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).
1) each qualification would hopefully serve some purpose
2) and could be ignored by users not interested in that purpose,
e.g.:
Query for :X and get back all :X and [] rdf:value :X.
Don’t care for other qualifications of [].
Go on with your life.
> 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.
From post-modernism to good old mechanics?
> 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).
I think you are giving up too early ;-)
>> 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.
Agreed, except that IMO DLs are not the problem here (by way of an exception ;-)
>> 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.
Actually… maybe they should be as general as possible? "Late binding semantics"? That might be easier to author but harder to use...
> 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.
It is a very complex problem and I wouldn’t dare to claim just yet that qualified statements are *the* solution to it. What seems clear to me is that they can play an important role as navigational aid. I share your concern about overly granular and orthogonalized structures. But what I like, and why I did point you to NdTerms, is that they seem to be rather sound and intuitively easy to grasp in principle (although tedious in practice). So maybe they can provide a suitable base for easier to use surface formalisms. Nested graphs come to mind.
If you think you can sidestep the whole problem with marginalias maybe you should go for it. If your application space is reasonably flat and uniform then there may not be a real reason to make it more complex just to fit into a much more complex world which hasn’t yet settled on the best way to represent itself.
> 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)).
Oh, thanks for that link. I had almost forgotten that mail. That is a very nice run down.
> 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,
Can you elaborate a bit?
> 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.
Well, the editors choose those examples because they don’t want to get near paradoxes and non-monotonicity. I’m not sure the users will be equally prudent.
>> 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" ] .
Ha! I hadn’t thought of that before. Very true.
> 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.
I’m not a fan of very specific vocabularies. In general I’m content with one :creator relation, I don’t want to have to use seperate properties to disambiguate if I created the recipe or the cake. In most cases context provided by application will be enough to disambiguate. When it isn’t an :identificationSemantics qualifier as sketched above should do the trick. This may put a little more stress on the machinery but it’s easier to handle for users I assume, at least if they are not only interested in one specific topic where one specific vocab is all they’ll ever need. I find this whole application centric thinking about vocabularies a bit difficult. It is probably very easy when all you want to do is SEO your recipe site but it risks balkanization.
>> 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?
I didn’t like embedded triples in 2017 when they were only syntactic sugar for RDF reification as I found them overly verbose and not scaling well to nested annotations, contrary to proper statement identifiers. As I discovered later proper identifiers are also a much better fit when annotating occurrences - almost the default use case I’d argue. I liked embedded triples even less when the proposed semantics was introduced in 2020. I don’t want to get religious about all this but if you use some syntactic tricks like Antoine’s
@prefix s: <http://www.w3.org/1999/02/22-rdf-syntax-ns#subject> .
@prefix p: <http://www.w3.org/1999/02/22-rdf-syntax-ns#predicate> .
@prefix o: <http://www.w3.org/1999/02/22-rdf-syntax-ns#object> .
@prefix : <http://example.com/> .
[s: :emp38; p: :jobTitle; o: "Assistant Designer"]
:accordingTo :emp22 .
what do you still need RDF-star for (except for creating trouble ;-)? This is not much less readable and concise than << :emp38 :jobTitle "Assistant Designer">> - but without a new semantics, without a new primitive.
>> 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?
Well, it depends. I hope I explained that above already.
> (In RDF we know they do,
In RDF yes, but in SPARQL we have counting semantics, as in PG, right?
> 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)).
In my understanding RDF standard reification elegantly gets around this set limitation as I explained above. The set semantics of RDF are IIUC a means to an end, not a crucial semantic feature. You are cordially invited to game them ;-)
> 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.
Well, there is that disconnect and it will always be there, one way or the other. If you think about Bob and Alice saying the same thing what do you actually think about? Do you think about two sayings of the same thing? Is that one or two things and is the saying disconnected from the thing itself or are Bob and Alice merging into one and the same entity as far as that saying is concerend? Is the saying itself disconnected from the act of saying it? Does it even exist if nobody ever said it?
I was until recently rather strict in my understanding of occurrences and thought they HAVE TO be tied to graphs. I was probably wrong about that but graphs CAN be a way to pin down individual occurrences. However when you need to speak about two different occurrences that’s not enough and you have several options:
- give them different identifiers per standard reification, preferably helped by some syntactic sugar
- put them in different graphs, preferably nestable
- create nodes that represent the different occurrences and connect them via appropriate relations, e.g. :occurrenceOf, to a representation of the type, e.g. a RDF-star embedded triple
but it all boils down to a disconnect between the abstract type, asserted or not, and the occurrence(s). When thinking more about the multiset issue recently I realized that any application — even explainable AI and versioning which I first thought were save — can run into a situation where they need to provide different references to the same type, for different occurrences. This is an important thing to think about as it has huge implications for usability: if single and multiple occurrences are modeled differently (and Pierre-Antoine in a footnote to the recently published example suggests that that is not a problem) then querying for *one or more* of them (e.g. as often you won’t know beforehand what to expect from the data) will require querying for both modelling syntaxes. That is never a good thing. Proper identifiers don’t have that problem.
>> 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.
No, I don’t think that’s what I want to say.
> 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.
RDF is an open, strictly monotonic model. That has repercussions on how statements have to be read. It’s just wrong to read the RDF statement
:Rick :marriedTo :Liz.
as saying that they are married now, forever, happily or whatever ideas one might have about marriages. It just says that there exists a marriage relation between those two entities, and that was, is and will forever be true - although there were two instances of that relation, both persons are dead already etc. One has to read every statement very conservativally if one wants to stay on the semantically safe side. Of course users and their applications will always be inclined to make more risky assumptions, but "you have been warned".
>> 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?
How would you encode their second marriage per the shorthand syntax? That’s only possible if the shorthand syntax is expanded to :occurrenceOf constructs and blank nodes are assigned to the occurrence identifiers. I've proposed that several times but to no avail.
And, to be annoyingly pedantic: the shorthand syntax as currently defined expands to embedded triples as defined per the proposed semantics, so the references are referentially opaque. We are not talking about the notorious Richard Burton himself but only about that person *IFF referenced as :Burton*, and the same for the the other terms. That is quite unsatisfying.
One more fun fact regarding referential opacity. Take:
<< :emp38 :jobTitle "Assistant Designer">>
:accordingTo :emp22 .
Assume now that a further processing step annotates the annotation:
<< << :emp38 :jobTitle "Assistant Designer">>
:accordingTo :emp22 >>
:ingestedAt "Feb 2022" .
:accordingTo is now referentially opaque. That property is part of the machinery, and there is really no reason to treat it as anything more than a replaceable tool. Yet you’d first have to define a TEP-version of :ingestedAt to ensure some flexibility of your tooling. And would that TEPing cascade down into the core statement?
>> 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?
While writing this mail I’m increasigly coming to the conclusion that RDF-star just can’t be saved. Annotating the type is the wrong approach as most of the time occurrences are annotated. That requiers the introduction of an intermediary node, destroying the simplicity. If intermediary nodes are only introduced when needed (for the second++ annotation) then querying always needs to take both versions into account, leading to more complicated queries. It ends in a mess all the time.
Proper identifiers are never as verbose as embedded triples and always "multiset-enabled". They can be syntactic sugar, expanding to standard reification. More sugar any time…
If annotating the type is really what’s needed, then define an analog to rdf:Statement. If faithfull syntactic reproduction of a statement is desired then define an RDF literal datatype (added bonus: the quotes will unmistakeably disambiguate the referentially opapque representation from any real "living" statement).
For a really exciting perspective go nested named graphs - not necessarily per default fully like Pat Hayes envisions them in [6] but that certainly as a possible extension.
> 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.
RDF-star would be not half as problematic if it wasn’t referentially opaque. That was a deliberate design decision, driven by N3 ideas, without any imperative necessity. It is the wrong design decision, and it is even dangerous.
> And I would like clarity about whether this "marginalia" interpretation
> is at odds with any emerging third form of "qualification".
As I said above, I think there are clear extremes - qualification vs annotation, internal vs external, or however one might name them - but there are many shades in between and where on that graded scale an annotation/qualification comes to sit doesn’t only depend on the author but also, or even more so, on the user and the application scenario, - so it materializes when querying, per query. Therefor those annotations/qualifications should be modeled in the same way, always and everywhere.
> And, again,
> whether further work on named graphs, soon or later on, might conflict
> with practices that might emerge now.
If you understand diverging modelling styles for the same problem as conflict, then yes: conflict! There is a longstanding popular belief that annotations on statements are orthogonal to annotations on graphs and some of the editors very explicitly subscribe to it. I think otherwise. I see no fundamental difference between an annotation on one, on two or on many statements and if the aim is a to have as few basic modelling primitives as possible then a graph-based approach IMO is more promising than a statement-based one.
> 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).
Not that I haven’t been in the same spot a few times before but in the end multiple occurrences of the same type break this concept, at least without proper identifiers or nested graphs. And if you have nested graphs, why bother with statement annotation? (So: let’s go for nested graphs!).
It was my mantra to the editors for quite some time to let embedded triples default to occurrences in the local graph. At least in the shortcut syntax. Nope. Maybe you have more luck. Still, make sure you have an idea how to handle multiple occurrences.
> 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).
Yes. But why wait? I’m not a good coder but I can’t imagine that that is much harder than implementing embedded triples. And it is much cleaner.
> 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.
I have that other idea that a named graph in a dataset, as long as it isn’t called - by a query that ranges over all graphs or explicitly in a FROM clause - is not part of the known universe. Calling it "activates" it. So we could sneak in definitions of a semantics the graph is to be called with at this point, or hard coded in its name. I see potential for all sorts of semantic crazyness much along the lines of what Dörthe Arndt and William van Woensel showed for N3 and what drives the N3 community’s interest in RDF-star (just better, because for graphs).
> 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.
Annotations IMO can be given inside as well as outside of some graph or other syntactic means. Because of my thinking about internal/external annotations/qualifications outlined above I would make them all belong to each term they touch, cascading down from graphs to all nested graphs to all triples contained in them all the way down to all the individual nodes and edges. All terms would actually be blank nodes with possibly a lot of qualifiers, the mandatory one being rdf:value. That would unambiguously settle what an annotation means. Everything else would be optimizations to make this manageable on the user interface level and in code, using (possibly nestable) named graphs.
But you can also take a different route and differentiate between internal qualifiers and external annotations. You’d probably use different syntaxes, RDF-star for statements and named graphs for graphs. You’d probably settle for different vocabularies so that you don’t have to search for say provenance in both statement qualifiers and graph annotations. But here it breaks already because why would provenance be constrained to statements OR graphs. You can surely find a way around that problem but it will surface time and again in other forms, causing lots of frustration, hackish gaming and lost opportunities because it is so exclusively either/or.
But the harder questions are those about referential opacity of graphs and where entailments belong. I believe Pat Hayes and Antoine Zimmermann debated about those questions long and hard. Take the RDF 1.1 Note on Datasets[7] and these two mails [8][9]. I have some ideas on that topic too but I’ll have to leave that to another mail.
Best,
Thomas
> 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
[7] https://www.w3.org/TR/rdf11-datasets/
[8] https://lists.w3.org/Archives/Public/semantic-web/2020Jul/0232.html
[9] https://lists.w3.org/Archives/Public/semantic-web/2020Jul/0233.html
Received on Tuesday, 8 February 2022 01:13:16 UTC