section 1.5: alternative second example

[william-vw]

There was a lack of response to #241 (comment) on the PR on improving examples in Section 1.5.

Hence, I repeat my comment here to make sure folks have noticed it.

Another second example could better fit the case where the triple corresponding to the triple term is asserted. IMO the "accordingTo" example becomes a bit less useful when the triple is also asserted.

This PR updates the text to accommodate the new example. If this has traction then I will attempt to make an SVG.

---

Preview | Diff

[niklasl]

I did comment on that (to the effect that more elaborate examples can go in the Primer or an FAQ); but I should motivate.

I don't think :accordingTo is less useful just because the proposition is a fact. On the contrary, relating claims to facts is one kind of provenance within the interpretation. The purpose of the current example and two illustrations was also to show the difference between a reified triple and an annotation in visual form.

Furthermore, without more elaborate explanation, this proposed example of a marriage having ended may mislead readers into thinking that this is somehow a conditional fact; which it isn't and cannot be under RDF semantics. And crucially, the fact is not claimed. It simply holds, independent of any circumstance. As an elaboration on this example, consider these simple facts, and circumstances in a reifying relationship to them:

prefix : <http://example.net/ns/>
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
base <http://example.org/>

<Alice> a :Person ;
  :givenName "Alice" ~ <Alice/birth> ;
  :familyName "Liddell" ~ <Alice/birth> ,
    "Hargreaves" ~ <Alice/marriage1> ;
  :birthDate "1852-05-04"^^xsd:date ~ <Alice/birth> ;
  :spouse <Reginald> ~ <Alice/marriage1> .

<Alice/birth> a :Birth ;
  :location <London> .

<Alice/marriage1> a :Marriage ;
  :date "1880-09-15"^^xsd:date .

All of these triples are simply true in the interpretation. Depending on application, the annotations can be used to understand which family name to use for Alice in various other circumstances. (This is of course just a sketch, more understanding of usage needs would further influence the conceptual design.) But this is all beyond the scope of RDF Concepts, probably beyond the Primer, and more suitable for an FAQ.

[william-vw]

Quick response here.

Sorry, I must have missed your answer.

Re the "claim" part, I (thought I )was basing myself on existing language in the spec -

In this example, the proposition denoted by the triple term (:Alice's name being "Alice") is not claimed to be true.
An asserted triple is a claim that the corresponding proposition is true.

I understand that the statements are simply true.

Re the suitability of the example, it can be up for discussion whether accordingTo is a good example for triple annotations or not. But I feel that having multiple examples is always a bonus. Using only 1 example may give the impression that this is the only foreseen use case of reification.

Perhaps a simpler alternative is to explicitly mention that there are other use cases; and, as you suggest, to link to a separate source with more examples (the primer, or an FAQ).

[niklasl]

You're right about the use of "claim" in the spec, and this is perhaps a dangerous use of language. I'd say, from the "outside", a graph is a claim (about the/a world), but the model "in itself" simply holds (provided that it is consistent). My main point is to avoid the implication that modelling claims within the interpretation can somehow affect what holds. We might want to make point explicitly?

I agree that the introduction does not cover all uses. I had hoped its mention of various kinds of reifiers already indicated that, but perhaps some improved wording can make it clearer. Linking to examples in the Primer can also be valuable there.

[niklasl]

I am also, like @pchampin and @afs pointed out, concerned about the proportion of this introductory section. Triple terms are not the main thing in RDF (and I'd argue that they should be sparingly used). Even with #238 adding to 1.1, section 1.5 on triple terms has more substantive example even as it is, than is perhaps an ideal balance in this first introduction to RDF.

[afs]

But I feel that having multiple examples is always a bonus.

Somewhere, probably; RDF Concepts, no.
See previous #241 (comment).

RDF Concepts is not a tutorial, nor a transition guide. There are other WG documents that are a better match.

[william-vw]

You're right about the use of "claim" in the spec, and this is perhaps a dangerous use of language. I'd say, from the "outside", a graph is a claim (about the/a world), but the model "in itself" simply holds (provided that it is consistent). My main point is to avoid the implication that modelling claims within the interpretation can somehow affect what holds. We might want to make point explicitly?

+1

I am also, like @pchampin and @afs pointed out, concerned about the proportion of this introductory section. Triple terms are not the main thing in RDF (and I'd argue that they should be sparingly used). Even with #238 adding to 1.1, section 1.5 on triple terms has more substantive example even as it is, than is perhaps an ideal balance in this first introduction to RDF.

But, they are a new part of RDF, they are a complicated concept, and really the primary reason for the new RDF version. It is understandable that the associated section would take up some more space. Also, a different second example would perhaps take one or two more sentences, nothing more.

[william-vw]

But I feel that having multiple examples is always a bonus.

Somewhere, probably; RDF Concepts, no. See previous #241 (comment).

RDF Concepts is not a tutorial, nor a transition guide. There are other WG documents that are a better match.

Hmm, I don't think that adding different examples to a document makes it a tutorial.

My frustration - which goes beyond this case, so I am not targeting you - is that there seems to be some "hidden rule" that W3C documents have to be dense and complicated. There was an EasierRDF movement a while back, which IIRC was motivated by a SW mailing list post expressing frustration by the opacity of W3C documents. There was some momentum there, which has now been lost.

I know that it is the primer that is supposed to be the "RDF's guide for dummies". But one could expect that people, once they've gotten interested, will move on to the other documents. We should avoid that what they find is a set of documents that take a PhD to understand. I understand the need for normative content, but it should not be the enemy of interpretability.

[afs]

Changing figure 2 looses the comparison to figure 1.

Explaining the time aspect needs a bigger example, such as @niklasl proposes. It also needs fit with 1.6 "RDF and Change over Time".

some "hidden rule" that W3C documents have to be dense and complicated

The documents come from the community.
Had a change of focus been taken up 2 years ago, then maybe. Section 1 would be significantly longer and quite possibly a separate output, leaving a core of sections 2 to 5.

[william-vw]

The documents come from the community.

If there is no rule, then why not add examples for comprehensibility :-)

Had a change of focus been taken up 2 years ago, then maybe.

Sorry, I'm not following.

[afs]

Material should go in RDF Primer or RDF New.

[hartig]

Material should go in RDF Primer or RDF New.

In fact, it may be an option to move (and merge) the whole content of the introduction section into the Primer.

[pchampin]

In fact, it may be an option to move (and merge) the whole content of the introduction section into the Primer.

I would not go that far! I think §1.5 as it stands belongs to RDF Concepts.

I sympathize with @william-vw's wish to illustrate the diversity of possible uses of reifiers, but

• as stated previously by me and others: making §1.5 bigger would create imbalance in the spec (recall that this is a non-substantive intro, not the meat of the spec)
• as pointed out by @niklasl here, there is some value in keeping the 2 examples aligned (i.e. differering only by the assertion of triple term)
• as pointed out by @niklas in the same comment, having an asserted triple annotated with an until date is another can of worm which I don't want to open here (again, an non-normative intro section, not an exhaustive tutorial)

So: +1 to add more numerous and diverse examples of reifiers, but in RDF Primer, not there.

[pchampin]

Actually, what we could do is replace " This section describes this common usage" in §1.5 with "This section briefly describes this common usage. For more examples, refer to the RDF Primer."

[william-vw]

as pointed out by @niklas in the same comment, having an asserted triple annotated with an until date is another can of worm which I don't want to open here (again, an non-normative intro section, not an exhaustive tutorial)

Good job on the YouTube video :-)

If the problem in particular is the "end date", then it is easy enough to change the example -

:Alice :familyName "Hargreaves" .
_:r0 rdf:reifies <<( :Alice :familyName "Hargreaves" )>> .
_:r0 :from "1880-09-15"^^xsd:date . 

Note that the example in the primer suffers from the same potential ambiguity with its "since" date. (I believe the triple from the triple term is also asserted there.)

Perhaps there should be a document somewhere that, well, explains all of this - do's, dont's, pitfalls - all that can help people use rdf-star properly.

(I personally dislike such a "jungle" of documents; this would add to it even more, unfortunately.)

But, if you agree, and folks don't think it should be part of the official specification, then where should it go - some type of "unofficial" primer? (assuming this is also not suitable for the primer, as it could be too difficult)

Is that what is meant by an FAQ - a kind of "catch all" for this type of content?

[niklasl]

@william-vw I think @franconi has a plan for a "Reification FAQ". (Do we have/want an issue to track that? I'd also love to lend a hand to it; as I've accreted a bunch of examples.) I understand the "jungle" problem, but a cohesive web of documents with distinct roles can be navigable.

In an "ideal world", we'd have a clear set of documents according to some principles (such as Diátaxis). I'm all for "Easy RDF", but there's no "one size fits all". There's already great community efforts such as Linked Data Patterns (also referenced from the Primer), etc. Consolidating and building on existing material may be harder but more valuable.

[afs]

Actually, what we could do is replace " This section describes this common usage" in §1.5 with "This section briefly describes this common usage. For more examples, refer to the RDF Primer."

PR #246 for that suggestion.

And now this discussion can be on a new issue on RDF Primer (AFAICS a PR can't be moved).

[TallTed]

I'm only up to 4 days ago in this discussion, but I wanted to make sure I didn't forget — we should include an example of disagreement, like where { :Fred :asserts <<( :Peggy :owns :Ferrari )>> } and { :DMV :asserts <<( :Peggy :rents :Ferrari )>> } and...

In other words, make use of the ability to talk about statements without asserting them.

[TallTed]

@william-vw — re: "help people use rdf-star properly"

rdf-star is long since deprecated. Long live RDF 1.2!