An introductory book on physics is classified with the topics it is about. This is done through a combination of automatic classification tools and editorial work of a cataloguing expert.
The process is:
- The Annif tool is used to compute suggestions for subject classifications of this book.
- A custom reasoner then looks up the topics, and uses eventual
skos:broaderrelations from them to automatically insert further suggestions of entailed broader topics into the graph. - Then the cataloguer asserts a selection of these computed triple occurrences in the graph, optionally keeping the remainder and commenting on why their suggestions are problematic.
The data is stored as one named graph, called the library record of the book, which is dedicated to the description of this book and integrally related resources (such as these annotated triple occurrences).
The entire library dataset is comprised of millions of such record graphs, the union of which forms the library knowledge graph.
This is the data we want, using Andy's suggested modification of the triple term notation:
<introduction-to-physics> a :Text ;
bf:classification <literature-education-physics> ,
<literature-education> ,
<literature> .
<#cls658581ed>
rdfx:occurrenceOf <<( <introduction-to-physics> bf:classification <literature-education-physics> )>> ;
bf:assigner <annif> ;
bf:date "2023-05-20T08:44:06Z" .
[] rdfx:occurrenceOf <<( <introduction-to-physics> bf:classification <literature-education-astrology> )>> ;
bf:assigner <annif> ;
bf:date "2023-05-20T08:44:06Z" .
[] rdfx:occurrenceOf <<( <introduction-to-physics> bf:classification <literature-education> )>> ;
bf:derivedFrom <#cls658581ed> ;
bf:date "2023-05-20T08:44:07Z" .
[] rdfx:occurrenceOf <<( <introduction-to-physics> bf:classification <literature> )>> ;
bf:derivedFrom <#cls658581ed> ;
bf:date "2023-05-20T08:44:07Z" .
[] rdfx:occurrenceOf <<( <introduction-to-physics> bf:classification <literature-education-astrology> )>> ;
rdfs:comment "Not correct." ;
bf:date "2023-05-20T14:03:11Z" .This is explicit and close to the abstract syntax. But it is also verbose, repetitive, and can be hard to read.
For one, the triple subject and predicate of the described triples is repeated for each occurrence, making it necessary to visually inspect and manually ensure that it is kept the same.
The compact annotation form is for representing the data more succinctly, cohesive and less repetitive. So the above can be expressed as:
<introduction-to-physics> a :Text ;
bf:classification <literature-education-physics> {| <#cls658581ed> |
bf:assigner <annif> ;
bf:date "2023-05-20T08:44:06Z" .
|} ,
<literature-education> {| bf:derivedFrom <#cls658581ed> |} ,
<literature> {| bf:derivedFrom <#cls658581ed> |} .
<< <introduction-to-physics> bf:classification <literature-education-astrology> >>
bf:assigner <annif> .
<< <introduction-to-physics> bf:classification <literature-education-astrology> >>
rdfs:comment "Not correct." .This is better, but has some problems:
A. The unasserted occurrences are still separate from the subject being described.
B. Syntax for the naming of the "primary" classification, <#cls658581ed> could be improved somewhat. For one it requires backtracking, and is thus a bit demanding on parsers.
C. Labelling and describing nested blank nodes doesn't follow the commonly flat design of Turtle, which doesn't allow both referencing the name of and locally further describing a resource in the object position. One good reason for that is that it is easier to visually look for the definition of a resource if it is always in the subject position when doing so. (Provided that its description isn't spread out in separate chunks of course, which Turtle does not enforce syntactically.)
A syntactic variant thereof, attempting to address these concerns, could:
- Use a dedicated character, here
=, to name the blank node of the occurrence. - Use a "comment" notation, here
--, used before objects objects (or perhaps predicates or objects) to make the triple they form unasserted (taken from my earlier RDF-star Annotation Occurrences proposal).
This would look like:
<introduction-to-physics> a :Text ;
bf:classification <literature-education-physics> {|= <#cls658581ed>|} ,
<literature-education> {| bf:derivedFrom <#cls658581ed> |} ,
<literature> {| bf:derivedFrom <#cls658581ed> |} ,
-- <literature-education-astrology> {| bf:assigner <annif> |} ,
-- <literature-education-astrology> {| rdfs:comment "Not correct." |} .
<#cls658581ed> bf:assigner <annif> ;
bf:date "2023-05-20T08:44:06Z" .Another variant, more radically redesigned (inspired by a suggestion by Richard Cyganiak in 2021), replacing the use of curly braces and pipes with a * (a star!), to mark the name of the annotated triple occurrence. That "name" could be a full blankNodePropertyList.
This would look like:
<introduction-to-physics> a :Text ;
bf:classification <literature-education-physics> *<#cls658581ed> ,
<literature-education> *[ bf:derivedFrom <#cls658581ed> ] ,
<literature> *[ bf:derivedFrom <#cls658581ed> ] ,
-- <literature-education-astrology> *[ bf:assigner <annif> ] ,
-- <literature-education-astrology> *[ rdfs:comment "Not correct." ] .
<#cls658581ed> bf:assigner <annif> ;
bf:date "2023-05-20T08:44:06Z" .(Care must be taken not to collide with SPARQL property paths of course, which this shouldn't do (being placed after the object). It could of course collide with e.g. literal mathematical equations in the object position in the future; so if that is a realistic possibility this should be altered. My two cents is that if such were ever introduced, they should at least have to be surrounded by parentheses, or similar.)
Here is a visualization of the most compact variant:
While there is value in staying close to the abstract syntax, Turtle does not always do so, since it has another design criteria of being easy, for humans, to both read and edit. User interfaces for visualization, interaction and editing are often closer to that kind of resource-centric design (rather than being about triples).