about_anne_bonny-triplified_reified.md

Statements about Statements about Anne Bonny

This is an example of using reified triples for expressing and annotating historical descriptions.

The starting point was the Wikidata description of Anne Bonny, edited into a simplified example form. Some references were followed to get a slightly more detailed account.

The result serves as an illustration of how many sources combine to form the basis of a truth-value judgement. Each source may in itself be partial and possibly inaccurate, and the resulting graph expresses the judgements, by choosing which triples to assert, and which to merely reference.

Model

The basic Person description is mainly based on Schema.org and Wikidata terms.

References are modelled as reifiers of statements derived from various source materials (usually written accounts). They can be given for any statements, including those about circumstances and other references.

A couple of Circumstances are also described, representing qualifications of simple facts as marginal accounts for context. In this example, they capture some temporal qualities underlying the simple relationships. That keeps the model closer to a flat set of facts, avoiding a more granular event-or-situation-oriented model up front. Circumstances can be based on other circumstances.

This makes use of the "many-to-many" nature of reifiers, where multiple triples can be reified at once, and several reifiers can be related to the same triple. References can be coarse-grained, even encompassing all of the statements derived from a source, or fine-grained, one reference per statement, or any combination thereof. Furthermore, a reference may be split up into several, to describe particular aspects pertaining only to a section or topic, or to reflect updates of source material. (Such "refactoring" of reifiers should not require changes in querying or otherwise consuming this data.)

Data

PREFIX : <http://example.org/ns#>
BASE <http://example.org/>

##
# These are the primary facts asserted by the publisher of this graph.

<Anne_Bonny> a :Person ;
    :name "Anne Bonny" ;
    :givenName "Anne"@en ;
    :familyName "Bonny"@en {| a :Circumstance ; :basedOn <#001> |} ;
    :parent <William_Cormac> ~ <#003> ~ <#005> ,
        <Mary_Brennan> ~ <#003> ~ <#005> ;
    :birthPlace <Kinsale,Cork_County,Ireland> ~ <#006> ~ <#008> ~ <#005> ;
    :birthDate "1697"^^:EDTF ~ <#007> ;
    :spouse <James_Bonny> ~ <#005> ~ <#001> ;
    :deathDate "?1733-12-29"^^:EDTF ~ <#009> ;
    :placeOfBurial <Spanish_Town,Jamaica> ~ <#009> .

##
# These are various documented sources of claims; asserted or just cited.
# Again, according to the publisher of this graph.

<#001> a :Circumstance ;
    :startDate "1716"^^:EDTF ~ <#005> .

<#002> a :Reference ;
    :source <https://www.wikidata.org/wiki/Q231549> ;
    :date "2024-08-14T13:27:33Z"^^:DateTime .

<#003> a :Reference ;
    :source <https://en.wikipedia.org/wiki/Anne_Bonny> ;
    :date "2024-08-14T10:05:22Z"^^:DateTime .

<#004> a :Reference ;
    :source <https://ru.wikipedia.org/wiki/Бонни,_Энн> ~ <#002> ;
    :date "2024-08-14T13:18:38Z"^^:DateTime .

<#005> a :Reference ;
    :source <http://www.encyclopedia.com/doc/1G2-3446400036.html> ~ <#002> ;
    :date "2024-08-14T12:48:07Z"^^:DateTime .

<#006> a :Reference ;
    :source <http://www.historyorb.com/people/anne-bonny> ~ <#002> ;
    :date "2024-08-14T10:07:03Z"^^:DateTime .

<#007> a :Reference ;
    :source <OxfordEncyclopediaOfWomenInWorldHistory> ~ <#002> ;
    :date "2024-08-14T13:22:24Z"^^:DateTime .

<#008> a :Reference ;
    :source <HistoricalDictionaryOfBritishWomen> ~ <#002> ;
    :date "2024-08-14T11:35:28Z"^^:DateTime .

<#009> a :Reference ;
    :source <SaintCatherinesParishBurialRecord> ~ <#002> ;
    :date "2024-08-14T13:13:31Z"^^:DateTime .

<#010> a :Reference ;
    :status :Disproved ~ <#003> ~ <#011> ;
    :source <ThePirateTrialOfAnneBonnyAndMaryRead> ~ <#003> ;
    :date "2024-08-14T12:59:06Z"^^:DateTime .

<#011> a :Reference ;
  :source <https://www.postandcourier.com/article_e7fc1e2c-101d-11e8-90b7-9fdf20ba62f8.html> ~ <#003>;
  :date "2024-07-10"^^:Date ~ <#003> .

##
# These are spurious claims made in the referenced sources.
# They are not considered true by the publisher of this graph.

<< <Anne_Bonny> :familyName "Brennan" ~ <#005> >> .
<< <Anne_Bonny> :familyName "Cormac" ~ <#005> >> .
<< <Anne_Bonny> :birthDate "?1700"^^:EDTF ~ <#006> >> .
<< <Anne_Bonny> :birthDate "?1700"^^:EDTF ~ <#008> >> .
<< <Anne_Bonny> :birthDate "1700-03-08"^^:EDTF ~ <#005> >> .
<< <Anne_Bonny> :deathDate "1782"^^:EDTF ~ <#006> >> .
<< <Anne_Bonny> :deathDate "1782"^^:EDTF ~ <#010> >> .
<< <Anne_Bonny> :deathDate "1782"^^:EDTF ~ <#004> >> .
<< <Anne_Bonny> :deathDate "1782-04-25"^^:EDTF ~ <#005> >> .
<< <Anne_Bonny> :deathPlace <Cork,Cork_County,Ireland> ~ <#010> >> .
<< <Anne_Bonny> :placeOfBurial <York_County,Virginia,USA> ~ <#004> >> .
<< <Anne_Bonny> :placeOfBurial <South_Carolina,USA> ~ <#005> >> .
<< <Anne_Bonny> :spouse <Joseph_Burleigh> ~ <#005> >> .
<< <Anne_Bonny> :spouse <Joseph_Burleigh> ~ <#66bcb8f8> >> .

<< <#66bcb8f8> a :Circumstance ~ <#005> >> .
<< <#66bcb8f8> :startPlace <Charles_Town,West_Virginia,USA> ~ <#005> >> .

The example nicely showcases the capabilities of RDF-star. However, it assumes a pretty closed system, i.e the publisher of the graph has and takes full control of the data. What if the publisher aims to simply aggregate data from different sources? Especially the propositional attitude if an annotated statement is endorsed or not may easily get lost, as some source may have annotated but not stated it, whereas another source does indeed state it. RDF as a data integration technology should try to make sure that such propositional attitude - which the syntax claims to express - is preserved also in a decentralized setting.

Editorial comment: the term identifiers, e.g. <66bcb0c5>, are pretty hard to read. For an example some continuous numbering would be easier to digest. Also, it's a bit too much detail. Two or three triples per usage scenario/idiom would be enough to get the gist of it.

The example nicely showcases the capabilities of RDF-star.

Thank you.

However, it assumes a pretty closed system, i.e the publisher of the graph has and takes full control of the data.

It assumes trust in the publisher and thus its published data.

What if the publisher aims to simply aggregate data from different sources?

If those sources are not trusted, the data from the publisher cannot be trusted.

The purpose of this example is to show the result of truth-value judgments, so it explicitly references the sources (mainly the Wikidata and Wikipedia aggregates, but also the assessments of their subsequent sources).

In the example, the Reference entities reify claims (trusted or not) in their role as references, to indicate that they were claimed in the sources (as defined in this domain of discourse).

The Circumstance entities reify (i.e. concretize) triples as the underlying, more specific circumstance of a simple, abstract relationship (or "zoomed-in model" if you will). Depending on the specific domain model chosen, circumstances may hold while their simple relationships "no longer" do so (such as with situational entities with a temporal extent, e.g. marriages or employments, but less likely so for more instantaneous events such as births, achievements or purchases).

Especially the propositional attitude if an annotated statement is endorsed or not may easily get lost,

Can you exemplify how that could happen, drawing from the given example?

as some source may have annotated but not stated it, whereas another source does indeed state it.

Do you mean that a source reifies but does not assert a triple?

If so, that is exemplified with the <#010> reference. In the Wikipedia article it is stated (reference <#003>) that <ThePirateTrialOfAnneBonnyAndMaryRead> is the source of claims about a certain death date and place. But the Wikipedia article itself does not contain those facts; in fact it states that this specific compound claim has been proven false, expressed here as :Disproved (it also provided a reference for that, which I just added to the example <#011>).

It claims that <#010> has been disproved as a whole. There are other claims about the specific purported death year of 1782, and AFAICT the true date is unknown. The example graph above, however, is apparently certain of the same claims as in <#009>, since it concurs with them. However, it does not explicitly state that <#009> is the source of this belief. But it could state so, if that was the case.

Which is the point here; correlation is not causation, and both networks of trust and the truth-value judgments that form them are, IMHO, complex things best modeled according to the needs of a specific domain. In Wikidata, <#009> might simply be marked as :Preferred. As a skeptic, I might prefer the circumstances of that preference too; but of course, then what's the source of those circumstances, etc. In epistemology the turtles go all the way down. So for practical reasons, at some point you just have to trust the publisher of a graph representation, and hence believe in that graph. How informed that belief is depends on how many references you can and do follow.

RDF as a data integration technology should try to make sure that such propositional attitude - which the syntax claims to express - is preserved also in a decentralized setting.

As I hope the above explains, I don't see the syntax as "claiming" to express propositional attitudes. I think such are decidedly in the domain of discourse. I also don't see the above as any more fragile than having a first order logic basis for "simply true" statements (rather than a richer modal logic). It's a model, not the territory, and as such is intrinsically constructed by simplified abstractions (directed and labelled binary relationships).

Within a graph, trust in these "atoms" is essential, and that trust has to be "out of band", i.e. part of the real world management. That means that creators, distributors and consumers of claims are part of the machinery of knowledge. They can all be described in a graph, at any depth of reference though. But trust in the descriptions is extrinsic to them. And in decentralized settings, to isolate such established domains of trust, we have datasets and named graphs.

---

Editorial comment: the term identifiers, e.g. <66bcb0c5>, are pretty hard to read. For an example some continuous numbering would be easier to digest.

Yes, that is better! I've updated the example. (Those epoch seconds were generated, being shorter than UUID:s for examples but still "realistic". But since I've simplified other parts even more here, it is more to form to follow your suggestion.)

Also, it's a bit too much detail. Two or three triples per usage scenario/idiom would be enough to get the gist of it.

Indeed, for a primer or best practice document, this is a bit too much. But I made this as a case study, using real data, and didn't want to compromise too much on detail. The point is to get a feel for what could be real data. I will keep these limits in mind though!

What do you do when you have a theory and two arguments:

<< :Foo :causes :Bar >> :because :A .
<< :Foo :causes :Bar >> :because :B .

How do you express that because of one of those arguments you believe the theory is true, but in the other argument you don't believe. The current proposal can't do it:

<< :Foo :causes :Bar >> :because :A .
<< :Foo :causes :Bar >> :because :B .
:Foo :causes :Bar .

Without more help from additional statements it's not clear if you consider A valid, and therefore the theory a fact, or :B, or :A and :B, or none of them. The reification mechanism essentially becomes a glorified comment sign, and any more specific information has to be provided by extra triples. That is the reason why Enrico dances around the question what a reified statement means, using undefined phrases like "it induces" which sometimes means it entails, and sometimes it doesn't . It simply depends on other statements.
This is not "statements about statements" to extend the expressiveness of RDF as a graph formalism, but only makes sense in the context of an E/R based modelling style where meaning is encapsulated in n-ary constructs, inaccessible to simple navigational queries. That is a graph only by name. It sure is useful, but not a replacement for a graph. And maybe it doesn't need statement annotation at all, just as Enrico suggested last Friday.

I'll attempt to address your question, although it goes beyond this specific example and into a more abstract discussion.

(Note that :Foo :causes :Bar is in this graph, and thus simply true in the following.)

In the following I'm assuming that :because is a property used on theories:

:because a rdf:Property ;
  rdfs:domain :Theory;
  rdfs:range :Reason .

First, let's explicitly name the theory we're to talk about:

<< :Foo :causes :Bar ~ <#TheoryA> >> :because :A .

Then either A) just explicitly model persons holding beliefs, and express that:

<Someone> :believesIn <#TheoryA> .

Or B) model proofs (rdfs:subClassOf :Reason), and state that :A is a proof:

:A a :Proof .

Then determine a theory as scientific if its reasons are proofs:

<#TheoryA> a :ScientificTheory .

This could be simplified, making :because stronger, by assigning :ScientificTheory and :Proof as its respective rdfs:domain and rdfs:range. Then the two type statements above are entailed.

For the other theory:

<< :Foo :causes :Bar ~ <#TheoryB> >> .

don't "endorse" its reason (don't express it as true):

<< <#TheoryB> :because :B ~ <#TheoryBReason> >> .

You can also "dismiss" the explanation as a myth:

<#TheoryBReason> a :Myth .

(This approach is quite like the example about hypotheses and proofs that I sent to the RDF-star WG list.)

You're right that the discussion is leading away from your use case, which - as I said above - is fine and well covered by the current proposal. So, sorry for continuing it, but I can't resist ;-)

With your response you're confirming my claim from above: "Without more help from additional statements it's not clear if you consider A valid, and therefore the theory a fact, or :B, or :A and :B, or none of them." Needing some additional statements may seem okay in this specific example, but in general will feel verbose as most annotations in practice are performed on statements that are considered true. They'd all need to add that extra but essential bit of information. Consider especially the annotation syntax which unmistakably annotates a stated statement, but according to your approach still requires an extra statement that states the obvious (and otherwise isn't even safe from round tripping to N-triples, or the triple store).

Your approach also doesn't narrow the gap between statement and annotation, but rather widens it as we now have a three valued system, adding detail and nuance where we don't want it:

• statements
• annotations on such statements considered true
• annotations on such statements irrespective of their truth value

The primary task of this WG is "statements about statements", not "statements about reifications (which just describe statements, no matter if asserted or not)". A secondary task is "statements about unasserted statements". Not addressing them explicitly but through extra statements is simpler to standardize, but leads to more verbosity and a more complex semantics in practice.

@niklasl You mentioned this example in the last Semantics TF meeting in the context of the discussion about rdf:states, and my comments above and here are mostly related to that issue. Re-reading this page I realized that I still owe you an answer to the following question:

Especially the propositional attitude if an annotated statement is endorsed or not may easily get lost,

Can you exemplify how that could happen, drawing from the given example?

I've become a bit unhappy with the description of the problem as concerning propositional attitudes. Let me put it this way: the current design can't represent annotations on an unasserted statement if that statement is also contained in the graph. In other words the current design struggles when confronted with diverging takes on what is true, i.e. asserted, or not.

To illustrate the problem I'm using a shortened but reasonably self-contained version of your example above:

# Facts
<Anne_Bonny> a :Person ;
    :name "Anne Bonny" ;
    :givenName "Anne"@en ;
    :familyName "Bonny"@en {| a :Circumstance ; :basedOn <#001> |} ;
    :birthDate "1697"^^:EDTF ~ <#007>  .

# Sources
<#001> a :Circumstance ;
    :startDate "1716"^^:EDTF ~ <#005> .
<#005> a :Reference ;
    :source <http://www.encyclopedia.com/doc/1G2-3446400036.html> ;
    :date "2024-08-14T12:48:07Z"^^:DateTime .
<#007> a :Reference ;
    :source <OxfordEncyclopediaOfWomenInWorldHistory> ~ <#005> ;
    :date "2024-08-14T13:22:24Z"^^:DateTime .
<#010> a :Reference ;
    :status :Disproved ~ <#003> ~ <#011> ;
    :source <ThePirateTrialOfAnneBonnyAndMaryRead> ~ <#005> ;
    :date "2024-08-14T12:59:06Z"^^:DateTime .

# Spurious claim
<< <Anne_Bonny> :birthDate "?1700"^^:EDTF ~ <#010> >> .

Now imagine another graph with information gathered from <AlicesComprehensivePiratesSite.org>. Here it's not clear how to assess the credibility of the source, and so although some claims seem contested the source is not marked as :Disproved. For lack of further information, the claims from that source are just documented but not asserted:

# Sources
<#012> a :Reference ;
    :source <http://www.AlicesComprehensivePiratesSite.org/pirates/AnneBonny> ;
    :date "2024-08-15T11:01:56Z"^^:DateTime .

# Spurious claims
<< <Anne_Bonny> :birthDate "1697"^^:EDTF ~ <#012> >> .  
<< <Anne_Bonny> :gender :Diverse ~ <#012> >> .  

Merging the two graphs results in adding <AlicesComprehensivePiratesSite.org> as a reference to the birth date that the publisher considers a fact.

# Facts
<Anne_Bonny> a :Person ;
    :name "Anne Bonny" ;
    :givenName "Anne"@en ;
    :familyName "Bonny"@en {| a :Circumstance ; :basedOn <#001> |} ;
    :birthDate "1697"^^:EDTF ~ <#007> ~ <#012> .                  # a second source was added

# Sources
<#001> a :Circumstance ;
    :startDate "1716"^^:EDTF ~ <#005> .
<#005> a :Reference ;
    :source <http://www.encyclopedia.com/doc/1G2-3446400036.html> ;
    :date "2024-08-14T12:48:07Z"^^:DateTime .
<#007> a :Reference ;
    :source <OxfordEncyclopediaOfWomenInWorldHistory> ~ <#005> ;
    :date "2024-08-14T13:22:24Z"^^:DateTime .
<#010> a :Reference ;
    :status :Disproved ~ <#003> ~ <#011> ;
    :source <ThePirateTrialOfAnneBonnyAndMaryRead> ~ <#005> ;
    :date "2024-08-14T12:59:06Z"^^:DateTime .
<#012> a :Reference ;
    :source <http://www.AlicesComprehensivePiratesSite.org/pirates/AnneBonny> ;
    :date "2024-08-15T11:01:56Z"^^:DateTime .

# Spurious claim
<< <Anne_Bonny> :birthDate "?1700"^^:EDTF ~ <#010> >> . 
<< <Anne_Bonny> :gender :Diverse ~ <#012> >> .  

As can be seen, under the current design it is not possible to add << <Anne_Bonny> :birthDate "1697"^^:EDTF ~ <#012> >> . to the "spurious claims" section. It can't be expressed that the statement is not endorsed when coming from that source, because it is endorsed as coming from some other and proven source. To the reader it will now seem that the publisher of this graph considers <AlicesComprehensivePiratesSite.org> a credible source, supporting Anne Bonny's birth date.

The publisher might now resort to further means, e.g. adding a new status value like :Unconfirmed to source <#012> or to the annotation itself, but that leads back to the question from my previous comment: do we expect queries to check all results for an annotation w.r.t. its trustworthiness, its endorsement by the publisher of the graph, or any other annotation w.r.t. its "status"? How many such status values would be needed, and should we standardize them?

For further discussion see my comment to issue #128.

@rat10 I do not interpret the ~ syntax as meaning "endorsed by" (any more than I would a footnote of a statement in any text; it could refer to a proof or a refutation, a source, sentiment, elaboration, etc.).

The syntax <Anne_Bonny> :birthDate "1697"^^:EDTF ~ <#012> is a combination of one assertion (simply true) and another which says that <#012> is some kind of reifier of that triple. If some reifiers are "reasons", that can be modeled; but as currently defined the annotation syntax only makes it easy for me, given a nice enough pretty-printed Turtle, to note, on the asserted triples, that there are reifiers of it.

(I've written about my position on this to you before.)

(Aside: It may be very useful to define a semantic extension for "known truths" as a class being the subset of triple terms known to be true. Then you'd be able to (meta-)model the relationship between reifiers and such truths. This could further build upon https://github.com/w3c/rdf-semantics/issues/49, if some form of that can be standardized.)

You have to take into consideration that there are two ways to use reifiers, not just one:

• annotation syntax, annotating an asserted statement
• double chevron syntax, annotating an unasserted statement

The difference is obvious on the surface, but is not reflected in the data model. That is the problem.

The ~has nothing to do with it. "Reasons" etc are also not the issue but orthogonal detail. However your remark that

the annotation syntax only makes it easy for me, given a nice enough pretty-printed Turtle, to note, on the asserted triples, that there are reifiers of it.

just illustrates the problem. The reifier, as currently defined, does not refer to the asserted triple. It refers to some statement of that type, asserted or not. IMO you have just confirmed my claim that the syntax leads to assumptions that are not reflected in the actual data. Mapping the annotation syntax to a property like the proposed rdfs:states, which clearly states that the annotation refers to an asserted triple, would reflect that assumption in the data model, to the benefit of every straight and mainstream use of RDF, and with only very little downside to those that need to refer to unasserted statements.

You have to take into consideration that there are two ways to use reifiers, not just one:

• annotation syntax, annotating an asserted statement
• double chevron syntax, annotating an unasserted statement

The difference is obvious on the surface, but is not reflected in the data model. That is the problem.

Unless you know what the syntax means, there is no obvious difference of interpretation (there are lots of surface differences; including indentation, choice of prefixes, etc.). Your claim is about what is apparent to you, but things are perceived differently based on previous knowledge/experience.

Given:

<x> :p <y>, <z> .

and:

<x> :p <y> . 
<x> :p <z> .

would you claim these have obvious differences in meaning that should be reflected in the data model?

The ~has nothing to do with it. "Reasons" etc are also not the issue but orthogonal detail. However your remark that

the annotation syntax only makes it easy for me, given a nice enough pretty-printed Turtle, to note, on the asserted triples, that there are reifiers of it.

just illustrates the problem. The reifier, as currently defined, does not refer to the asserted triple. It refers to some statement of that type, asserted or not. IMO you have just confirmed my claim that the syntax leads to assumptions that are not reflected in the actual data.

I did not mean "it" as the triple in its role of being asserted, but as a triple, the reference to which I'd use a triple term if this shorthand didn't exist. That is a convenence addition to syntax for asserting the triple; similar to how I can avoid typing the subject and predicate twice in the example I just gave above. Again, I am not talking about reifying "the assertion" of that triple.

Mapping the annotation syntax to a property like the proposed rdfs:states, which clearly states that the annotation refers to an asserted triple, would reflect that assumption in the data model, to the benefit of every straight and mainstream use of RDF, and with only very little downside to those that need to refer to unasserted statements.

Do you mean "the triple, known to be true" or "the assertion of the triple", or something else?

You have to take into consideration that there are two ways to use reifiers, not just one:

• annotation syntax, annotating an asserted statement
• double chevron syntax, annotating an unasserted statement

The difference is obvious on the surface, but is not reflected in the data model. That is the problem.

Unless you know what the syntax means, there is no obvious difference of interpretation (there are lots of surface differences; including indentation, choice of prefixes, etc.). Your claim is about what is apparent to you, but things are perceived differently based on previous knowledge/experience.

Given:

<x> :p <y>, <z> .

and:

<x> :p <y> . 
<x> :p <z> .

would you claim these have obvious differences in meaning that should be reflected in the data model?

Your argument reminds me of Peter's argument that likens the two syntaxes to different serializations of blank nodes, although maybe not that bizarre. I think you are profoundly misreading the intuitions evoked by the syntactic sugar of Turtle-star. Sure, this is subjective, but still: in absence of a user study I can only strongly disagree.

The ~has nothing to do with it. "Reasons" etc are also not the issue but orthogonal detail. However your remark that

the annotation syntax only makes it easy for me, given a nice enough pretty-printed Turtle, to note, on the asserted triples, that there are reifiers of it.

just illustrates the problem. The reifier, as currently defined, does not refer to the asserted triple. It refers to some statement of that type, asserted or not. IMO you have just confirmed my claim that the syntax leads to assumptions that are not reflected in the actual data.

I did not mean "it" as the triple in its role of being asserted, but as a triple, the reference to which I'd use a triple term if this shorthand didn't exist. That is a convenence addition to syntax for asserting the triple; similar to how I can avoid typing the subject and predicate twice in the example I just gave above.

This may be one of the reasons why we differ so much. Of course, even without the disagreement about the interpretation of syntactic sugar we probably disagree also about the need to have an annotation mechanism that decidely refers to stated statements (and for which the annotation syntax would be my preferred vehicle).

Again, I am not talking about reifying "the assertion" of that triple.

Mapping the annotation syntax to a property like the proposed rdfs:states, which clearly states that the annotation refers to an asserted triple, would reflect that assumption in the data model, to the benefit of every straight and mainstream use of RDF, and with only very little downside to those that need to refer to unasserted statements.

Do you mean "the triple, known to be true" or "the assertion of the triple", or something else?

We only speak about statements made in specific graphs (i.e. not statements made in other ("external") graphs), so the difference you ask about makes no sense to me - a triple is known to be true if it is asserted in a graph - and I see nothing else (and I use the terms "triple" and "statement" pretty much interchangeably - I hope that is not a source of confusion).