Skip to content

Instantly share code, notes, and snippets.

@niklasl
Last active October 23, 2024 12:57
Show Gist options
  • Select an option

  • Save niklasl/f4a5dee1b991ff5a19a33360c6fd3078 to your computer and use it in GitHub Desktop.

Select an option

Save niklasl/f4a5dee1b991ff5a19a33360c6fd3078 to your computer and use it in GitHub Desktop.

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

niklasl commented Oct 22, 2024

Copy link
Copy Markdown
Author

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?

@rat10

rat10 commented Oct 23, 2024

Copy link
Copy Markdown

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment