2b:null 2c:["$","title",null,{"children":"A Semaku perspective on RDF-star | James Anderson | Observable"}] 31:T357a,[this is an early version of John Walker's post about RDF star. a revised version is to be found at [https://semaku.com/post/why-im-worried-about-rdf-star/](https://semaku.com/post/why-im-worried-about-rdf-star/). ] In a recent post, Dean Allemang explained [why he's not excited about RDF-star](https://medium.com/@dallemang/why-im-not-excited-about-rdf-star-5f1993fd0ead). In this post I want to expand on Dean's post with more concrete examples to illustrate why I'm worried about RDF-star. In the flights example, Dean mentions that using RDF-star would encourage poor modeling practice. So how exactly would that manifest if we choose to model multiple flights with multiple triples: ```turtle :NYC :connection :SFO . :NYC :connection :SFO . :NYC :connection :SFO . ``` First we note that "an RDF-star triple is an abstract entity whose identity is entirely defined by its subject, predicate, and object" and "this unique triple (s, p, o) can be quoted as the subject or object of multiple other triples, but must be assumed to represent the same thing everywhere it occurs". So in the above example, we have the same RDF-star triple asserted three times. This is already familiar for experienced RDF users as, when processing a graph with duplicate triples, those duplicate statements may be de-duplicated. When quoting this triple in RDF-star, a novice user might assert additional information about the multiple flights as follows: ```turtle :NYC :connection :SFO . << :NYC :connection :SFO >> :departureGate "10" ; :departureTime "2023-04-22T00:00:00Z"^^xsd:dateTime ; :arrivalTime "2023-04-22T06:00:00Z"^^xsd:dateTime . :NYC :connection :SFO . << :NYC :connection :SFO >> :departureGate "20" ; :departureTime "2023-04-23T00:00:00Z"^^xsd:dateTime ; :arrivalTime "2023-04-23T06:00:00Z"^^xsd:dateTime . :NYC :connection :SFO . << :NYC :connection :SFO >> :departureGate "30" ; :departureTime "2023-04-24T00:00:00Z"^^xsd:dateTime ; :arrivalTime "2023-04-24T06:00:00Z"^^xsd:dateTime . ``` Or the equivalent using [annotation syntax](https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html#annotation-syntax): ```turtle :NYC :connection :SFO {| :departureGate "10" ; :departureTime "2023-04-22T00:00:00Z"^^xsd:dateTime ; :arrivalTime "2023-04-22T06:00:00Z"^^xsd:dateTime . |} . :NYC :connection :SFO {| :departureGate "20" ; :departureTime "2023-04-23T00:00:00Z"^^xsd:dateTime ; :arrivalTime "2023-04-23T06:00:00Z"^^xsd:dateTime . |} . :NYC :connection :SFO {| :departureGate "30" ; :departureTime "2023-04-24T00:00:00Z"^^xsd:dateTime ; :arrivalTime "2023-04-24T06:00:00Z"^^xsd:dateTime . |} . ``` However, running this through the Jena Riot command-line tool with formatted output, we immediately see a problem: ``` :NYC :connection :SFO . << :NYC :connection :SFO >> :arrivalTime "2023-04-24T06:00:00Z"^^xsd:dateTime , "2023-04-23T06:00:00Z"^^xsd:dateTime , "2023-04-22T06:00:00Z"^^xsd:dateTime ; :departureGate "30" , "20" , "10" ; :departureTime "2023-04-24T00:00:00Z"^^xsd:dateTime , "2023-04-23T00:00:00Z"^^xsd:dateTime , "2023-04-22T00:00:00Z"^^xsd:dateTime . ``` Because the quoted triple represents the same thing (resource) everywhere it occurs, we have clashing/conflicting use of the resource identifier (being the quoted triple). Thus, we end up with all the statements being about the same thing, not three different flights. So it is impossible to know which departure gate relates to which departure time, not ideal if we don't want to miss our flight! Querying the graph using SPARQL-star query further illustrates the effect: ```sparql select * where { :NYC :connection :SFO {| :departureGate ?gate ; :departureTime ?departs ; :arrivalTime ?arrives |} . } ``` Gives the results: ``` -------------------------------------------------------------------------------------- | gate | departs | arrives | ====================================================================================== | "10" | "2023-04-24T00:00:00Z"^^xsd:dateTime | "2023-04-23T06:00:00Z"^^xsd:dateTime | | "10" | "2023-04-24T00:00:00Z"^^xsd:dateTime | "2023-04-24T06:00:00Z"^^xsd:dateTime | | "10" | "2023-04-24T00:00:00Z"^^xsd:dateTime | "2023-04-22T06:00:00Z"^^xsd:dateTime | | "10" | "2023-04-22T00:00:00Z"^^xsd:dateTime | "2023-04-23T06:00:00Z"^^xsd:dateTime | | "10" | "2023-04-22T00:00:00Z"^^xsd:dateTime | "2023-04-24T06:00:00Z"^^xsd:dateTime | | "10" | "2023-04-22T00:00:00Z"^^xsd:dateTime | "2023-04-22T06:00:00Z"^^xsd:dateTime | | "10" | "2023-04-23T00:00:00Z"^^xsd:dateTime | "2023-04-23T06:00:00Z"^^xsd:dateTime | | "10" | "2023-04-23T00:00:00Z"^^xsd:dateTime | "2023-04-24T06:00:00Z"^^xsd:dateTime | | "10" | "2023-04-23T00:00:00Z"^^xsd:dateTime | "2023-04-22T06:00:00Z"^^xsd:dateTime | | "20" | "2023-04-24T00:00:00Z"^^xsd:dateTime | "2023-04-23T06:00:00Z"^^xsd:dateTime | | "20" | "2023-04-24T00:00:00Z"^^xsd:dateTime | "2023-04-24T06:00:00Z"^^xsd:dateTime | | "20" | "2023-04-24T00:00:00Z"^^xsd:dateTime | "2023-04-22T06:00:00Z"^^xsd:dateTime | | "20" | "2023-04-22T00:00:00Z"^^xsd:dateTime | "2023-04-23T06:00:00Z"^^xsd:dateTime | | "20" | "2023-04-22T00:00:00Z"^^xsd:dateTime | "2023-04-24T06:00:00Z"^^xsd:dateTime | | "20" | "2023-04-22T00:00:00Z"^^xsd:dateTime | "2023-04-22T06:00:00Z"^^xsd:dateTime | | "20" | "2023-04-23T00:00:00Z"^^xsd:dateTime | "2023-04-23T06:00:00Z"^^xsd:dateTime | | "20" | "2023-04-23T00:00:00Z"^^xsd:dateTime | "2023-04-24T06:00:00Z"^^xsd:dateTime | | "20" | "2023-04-23T00:00:00Z"^^xsd:dateTime | "2023-04-22T06:00:00Z"^^xsd:dateTime | | "30" | "2023-04-24T00:00:00Z"^^xsd:dateTime | "2023-04-23T06:00:00Z"^^xsd:dateTime | | "30" | "2023-04-24T00:00:00Z"^^xsd:dateTime | "2023-04-24T06:00:00Z"^^xsd:dateTime | | "30" | "2023-04-24T00:00:00Z"^^xsd:dateTime | "2023-04-22T06:00:00Z"^^xsd:dateTime | | "30" | "2023-04-22T00:00:00Z"^^xsd:dateTime | "2023-04-23T06:00:00Z"^^xsd:dateTime | | "30" | "2023-04-22T00:00:00Z"^^xsd:dateTime | "2023-04-24T06:00:00Z"^^xsd:dateTime | | "30" | "2023-04-22T00:00:00Z"^^xsd:dateTime | "2023-04-22T06:00:00Z"^^xsd:dateTime | | "30" | "2023-04-23T00:00:00Z"^^xsd:dateTime | "2023-04-23T06:00:00Z"^^xsd:dateTime | | "30" | "2023-04-23T00:00:00Z"^^xsd:dateTime | "2023-04-24T06:00:00Z"^^xsd:dateTime | | "30" | "2023-04-23T00:00:00Z"^^xsd:dateTime | "2023-04-22T06:00:00Z"^^xsd:dateTime | -------------------------------------------------------------------------------------- ``` We end up with the cross-product of the three values for each of `:departureGate`, `:departureTime` and `:arrivalTime`. The RDF-star specification recognizes the distinction between global triples and specific asserted occurences of triples. The latter requires additional nodes in the graph to represent the distinct occurences of the triple. Following the approach presented in the specification: ```turtle :NYC :connection :SFO . [] :occurenceOf << :NYC :connection :SFO >> ; :departureGate "10" ; :departureTime "2023-04-22T00:00:00Z"^^xsd:dateTime ; :arrivalTime "2023-04-22T06:00:00Z"^^xsd:dateTime . [] :occurenceOf << :NYC :connection :SFO >> ; :departureGate "20" ; :departureTime "2023-04-23T00:00:00Z"^^xsd:dateTime ; :arrivalTime "2023-04-23T06:00:00Z"^^xsd:dateTime . [] :occurenceOf << :NYC :connection :SFO >> ; :departureGate "30" ; :departureTime "2023-04-24T00:00:00Z"^^xsd:dateTime ; :arrivalTime "2023-04-24T06:00:00Z"^^xsd:dateTime . ``` Though we end up so close to a 'proper' domain model that it's a better proposition to improve the model to start with. Other options might be to retain the context of the qualifying statements using named graphs, or add more recursive levels of reification. Neither is particularly appealing. Ultimately the advice on [N-ary relations and reification in RDF](https://www.w3.org/TR/swbp-n-aryRelations/#RDFReification) in the (draft) Working Group Note "Defining N-ary Relations on the Semantic Web" remains relevant, with some tweaks: > It may be natural to think of ~~RDF reification~~ **RDF-star** when representing n-ary relations. We do not want to use ~~the RDF reification vocabulary~~ **RDF-star** to represent n-ary relations in general for the following reasons. ~~The RDF reification vocabulary~~ **RDF-star** is designed to talk about *statements*---individuals that are instances of ~~`rdf:Statement`~~ `rdf-star:Triple`. A statement is a subject, predicate, object triple and ~~reification in RDF~~ **RDF-star** is used to ~~put~~ **assert** additional information about this triple. This information may include the source of the information in the triple, for example. In n-ary relations, however, additional arguments in the relation do not usually characterize the statement but rather provide additional information about the relation instance itself. Thus, it is more natural to talk about instances of a diagnosis relation or a purchase rather than about a statement. In the use cases that we discussed in the note, the intent is to talk about instances of a relation, not about statements about such instances. ## Triples and occurences and qualification Even when using RDF-star to make statements about statements, we still need to carefully consider how we model those meta-statements. A good example is if we want to model assertions and retractions of statements (who said what and when). Consider the following RDF-star triple: ```turtle << _:a :name "Alice" >> :statedBy :bob. ``` Should we want to model *when* Bob stated this, what would be a good approach? As shown above, we cannot make more statements about the triple `<< _:a :name "Alice" >>` without potential clashes. Instead, we need to talk about an occurence of the triple. Given that `rdfs:Literal` is a subclass of `rdfs:Resource`, it follows that any literal is a resource. Similarly a quoted tripe is itself a resource. So, if we want to relate the quoted triple `<< _:a :name "Alice" >>` with Bob and a timestamp, then we have an n-ary relation. As the intent is to talk about the instance of the relation, rather than the statement of the relation, we might introduce some 'Assertion' class: ```turtle [] a :Assertion ; :occurenceOf << _:a :name "Alice" >> ; :agent :bob ; :atTime "2023-04-30T20:40:40"^^xsd:dateTime ``` ## Interoperability with Property Graphs Using RDF-star to provide interoperability with Property Graphs is mentioned in both the [RDF-star Working Group Charter](https://www.w3.org/2022/08/rdf-star-wg-charter/) and [RDF-star Use Cases and Requirements](https://www.w3.org/rdf-star-ucr/). The Property Graphs and object-oriented databases that I've encountered use the edges to represent instances of relations, as opposed to some globally unique triple. As in, there may be multiple instances of edges/relations with the same relation type between the same nodes/relations, but with different attributes and values on the edges. A natural representation of Property Graph data in RDF is therefore to introduce a qualified class per relation type. Arguably RDF-star is not necessary for this, but if we wish to introduce 'simple' binary relations in addition to qualified relations, then using quoted triples would allow to relate those. To illustrate this, representing a PG relation as follows: ``` << :Alice :worksFor :ACME >> :role :CEO ; :since 2010 ; :probability 0.8 ; :source . ``` Would introduce the issues described above if we were to scrape data about Alice's employment details from multiple sources that gave differing accounts of the employment history. To avoid this, we can represent the relation as the instance of some class: ``` [] a :EmployeeRole ; :occurenceOf << :Alice :worksFor :ACME >> ; :roleName :CEO ; :since 2010 ; :probability 0.8 ; :source . ``` ## Usage with PROV-O Using quoted statements to relate instances of a relation to the unqualified triple could present an useful way to lookup qualifying information. This pattern could also be useful when incrementally evolving a model where we only discover the need to reify certain relations as requirements emerge. Rather than prospectively modeling all those classes up-front, we can start with a minimum-viable model and extend later as needed. We can illustrate this using examples based on PROV-O. PROV-O Qualified classes and properties provide elaborated information about binary relations asserted using Starting Point and Expanded properties. Where we might start by talking about some activity using the starting-point properties: ```turtle :sortActivity a prov:Activity ; prov:startedAtTime "2011-07-16T01:52:02Z"^^xsd:dateTime ; prov:used :datasetA ; prov:generated :datasetB . ``` Later we might figure out that we needed to express the role of `:datasetA` whereby we can retain the relation to the original triple: ``` :sortActivity a prov:Activity ; prov:startedAtTime "2011-07-16T01:52:02Z"^^xsd:dateTime ; prov:qualifiedUsage [ a prov:Usage ; prov:entity :datasetA ; ## The entity used by the prov:Usage prov:hadRole :inputToBeSorted ; ## the role of the entity in this prov:Usage prov:specializationOf << :sortActivity prov:used :datasetA >> ; ]; prov:used :datasetA ; ## retain the original asserted statement for backwards compatibility prov:generated :datasetB; . ``` ## Conclusion How to promote good RDF modeling practices? How to know when we talk about instances of relations versus statements? How to know when we talk about a triple versus an occurrence of a triple? 32:[] 2f:{"id":"c2e1752c474073a7","slug":"semaku-rdf-star-post","title":"A Semaku perspective on RDF-star","thumbnail":"d59a9517cb7b448e4b9b37e89f7570cc2b181f935ff9d4554c1e9467c63ce778","access_level":"public","create_time":"$D2023-05-17T14:26:28.576Z","update_time":"$D2024-08-15T21:12:16.870Z","view_time":null,"first_public_time":"$D2023-05-17T14:26:28.576Z","fork":false,"stars":0,"starred":false,"owner":{"type":"team","id":"b452fd69977f5701","login":"lomoramic","name":"James Anderson","avatar_url":"https://avatars-next.observableusercontent.com/dc520bbc733259f2913522cf1d50607777b98a3083f290a6f182534561896497","tier":"starter_2024"},"version":12,"publish_version":null,"role":null,"authored":false,"authors":[],"members":[{"type":"individual","id":"987c90ad70c449c1","login":"lomoramic","name":"James Anderson","avatar_url":"https://avatars-next.observableusercontent.com/dc520bbc733259f2913522cf1d50607777b98a3083f290a6f182534561896497","tier":null,"role":"editor"},{"type":"team","id":"b452fd69977f5701","login":"lomoramic","name":"James Anderson","avatar_url":"https://avatars-next.observableusercontent.com/dc520bbc733259f2913522cf1d50607777b98a3083f290a6f182534561896497","tier":"starter_2024","role":"viewer"}],"comments":[],"custom_thumbnail":false,"trashed":false,"subscribed":null,"forks":0,"collection":null,"type":"notebook","body":{"title":"A Semaku perspective on RDF-star","cells":[{"id":0,"value":"# A Semaku perspective on RDF-star","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined"},{"id":5,"value":"$31","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined"}],"files":"$W32","stdlib":"1","titling":"auto"}} 30:"$2f:body"