Representing complicated sentences using RDF syntax

Question

I am new to RDF and I have one question about RDF.

With some simple sentence like : "Ann studies Math", there's no problem to represent it using RDF.

But with more complicated sentences such as: "Mr Parker teaches Machine Learning and uses the book named ML-for-newbie", I mean Mr Parker uses that book to prepare his lectures. There're 3 objects : Mr Parker, Machine Learning, ML-for-newbie; 2 predicates: teach, use. So how to represent this sentence in RDF? As I know, one RDF statement is like Subject --predicate--> Object, and the 3 objects and 2 predicates make me confused :(

Plz Help, thanks!

Answer 1

In your case, you could either decompose these sentences in 3 RDF statements or use a blank node.

Examples of decomposition, the course has its own URI (:Course999):

:Mr_Parker    :teaches    :Course999 .
:Course999    :courseName    "Machine Learning" .
:Course999    :hasSupportBook    "ML-for-newbies" .

With anonymous nodes (blank node _:b1), it's the same principle but the course is not explicitly captured:

:Mr_Parker    :teaches    _:b1 .
_:b1    :courseName    "Machine Learning" .
_:b1    :hasSupportBook    "ML-for-newbies" .

Now as mentioned in the comments, the string "ML-for-newbies" is actually not a book, it just represent the title of the book. So you could add more triples to capture extra information about this item (like the author of this book for instance). You can think of re-using already developed vocabulary for this task (like the Dublin Core):

:Mr_Parker    :teaches    _:b1 .
_:b1    :hasSupportBook    :book2 .
:book2    dcterms:title    "ML-for-newbies" .
:book2    dcterms:creator    "John Smith" .

... and then here the string represent just the name of the author but not the author itself (like for the book), so you could expand your triples even more by representing this entity type too if needed.

Answer 2

The accepted answer is good and has examples, but it's worth having a look at the W3C's Working Group Note Defining N-ary Relations on the Semantic Web that discusses these representation issues. The approach in the accepted answer is Pattern 1: introducing a new class for a relation in that note. There's also a Pattern 2: Using lists for arguments in a relation, but that feels clumsier, and I don't think as many people take that approach.