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> >> .

@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).