How can I express additional information (time, probability) about a relation in RDF?
Asked Answered
A

2

8

I know that I can represent any relation as a RDF triplet as in:

Barack Obama -> president of -> USA

(I am aware that this is not RDF, I am just illustrating)

But how do I add additional information about this relation, like for example the time dimension? I mean he is in his second presidential period and any period last only for a lapse of time. And, how about after and before his presidential periods?

Adrenalin answered 3/10, 2015 at 13:35 Comment(3)
This is probably too broad for Stack Overflow. You've got lots of options. You could store your data in a dataset with named graphs capturing some content. Or you could make it an n-ary relationship: :Obama :hasRole [ :type :President ; :country :USA ; :begin ... ; :end ...].Samford
Thanks @JoshuaTaylor could you point me to a reference or a book, please?Adrenalin
I can't really do any better than Google would, so you might have a look at the classic Defining N-ary Relations on the Semantic Web. For datasets, have a look at the SPARQL standard.Samford
G
15

There are several options to do this. I'll illustrate some of the more popular ones.

Named Graphs / Quads

In RDF, named graphs are subsets of an RDF dataset that are assigned a specific identifier (the "graph name"). In most RDF databases, this is implemented by adding a fourth element to the RDF triple, turning it from a triple into a "quad" (sometimes it's also called the 'context' of the triple).

You can use this mechanism to express information about a certain collection of statements. For example (using pseudo N-Quads syntax for RDF):

:i1 a :TimePeriod .
:i1 :begin "2009-01-20T00:00:00Z"^^xsd:dateTime .
:i1 :end "2017-01-20T00:00:00Z"^^xsd:dateTime .

:barackObama :presidentOf :USA :i1 .

Notice the fourth element in the last statement: it links the statement "Barack Obama is president of the USA" to the named graph identified by :i.

The named graphs approach is particularly useful in situations where you have data to express about several statements at once. It is of course also possible to use it for data about individual statements (as the above example illustrates), though it may quickly become cumbersome if used in that fashion (every distinct time period will need its own named graph).

Representing the relation as an object

An alternative approach is to model the relation itself as an object. The relation between "Barack Obama" and "USA" is not just that one is the president of the other, but that one is president of the other between certain dates. To express this in RDF (as Joshua Taylor also illustrated in his comment):

:barackObama :hasRole :president_44 .
:president_44 a :Presidency ;
         :of :USA ;
         :begin "2009-01-20T00:00:00Z"^^xsd:dateTime ;
         :end "2017-01-20T00:00:00Z"^^xsd:dateTime .

The relation itself has now become an object (an instance of the "Presidency" class, with identifier :president_44).

Compared to using named graphs, this approach is much more tailored to asserting data about individual statements. A possible downside is that it becomes a bit more complex to query the relation in SPARQL.

RDF Reification

Not sure this approach actually still counts as "popular", but RDF reification is the historically W3C-sanctioned approach to asserting "statements about statements". In this approach we turn the statement itself into an object:

 :obamaPresidency a rdf:Statement ;
         rdf:subject :barackObama ;
         rdf:predicate :presidentOf ;
         rdf:object :USA ;
         :trueBetween [
                :begin "2009-01-20T00:00:00Z"^^xsd:dateTime ;
                :end "2017-01-20T00:00:00Z"^^xsd:dateTime .
         ] .

There's several good reasons not to use RDF reification in this case, however:

  1. it's conceptually a bit strange. The knowledge that we want to express is about the temporal aspect of the relation, but using RDF reification we are saying something about the statement.
  2. What we have expressed in the above example is: "the statement about Barack Obama being president of the USA is valid between ... and ...". Note that we have not expressed that Barack Obama actually is the president of the USA! You could of course still assert that separately (by just adding the original triple as well as the reified one), but this creates a further duplication/maintenance problem.
  3. It is a pain to use in SPARQL queries.

As Joshua also indicated in his comment, the W3C Note on defining N-ary RDF relations is useful to look at, as it goes into more depth about these (and other) approaches.

Gaylene answered 9/11, 2015 at 22:20 Comment(5)
Neophyte when it comes to RDF, but my first reaction was president is text book class object. In fact, it seems you could validate the date value many years into the future.Pablo
@Pablo not sure what you're getting at to be honest.Gaylene
oops. Using the StackApp from the train on my way to work--I meant to comment on the OP. Basically I was suggesting, as you answered with "An alternative approach is to model the relation itself as an object." , even if you didn't know anything about RDF definitions, the problem has the characteristics of the archetypical example of a class-object.Pablo
As a side note, Google wasn't satisfied with any of these approaches so they started github.com/google/badwolfTandie
@berezovskiy interesting. Stupid approach - the whole point of RDF is to have an interoperable standard. But interesting.Gaylene
H
1

RDF*, or RDF-star, allows expressing additional information about an RDF triple, allowing nested structures such as:

<< :BarackObama :presidentOf :USA >> :since :2009

Bit of a contrived example (since the term of presidency could be expressed by simply normalizing data structure), but it’s quite useful for expressing “external” concerns (such as probability or provenance).

See Olaf’s blog post and, for technical details, https://www.w3.org/2021/12/rdf-star.html.

I’m pretty sure Apache Jena supports it already, not quite sure about other products like Neo4j.

Hekking answered 17/2, 2023 at 3:17 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.