-
Notifications
You must be signed in to change notification settings - Fork 1
Concrete Example of our Model
In this page we are going to use a running example to explain our data model.
Since Wikidata does not differentiate between classes and items, we are going using shapes to distinguish them:
- ▭ for Classes
- ◯ for Items
So our example publication will be a circle in this case since its an item:
Every publication in our data is an instance of the base class Work:
Here we see the first property in our model: instance of
. It accepts an Item as value, and this item is the parent class of the given instance.
Going from this example, we can get all of the publications in our data by simply getting all the items that are instance of the Work class.
#get all publications
SELECT ?publication WHERE {
?publication P<instance of> Q<class: Work>
}
Lets add the following data to our example and see how does that look like in the SPARQL database. Note: this data is fictional.
Key | Value |
---|---|
label | Energy of the Biosphere |
authors | Lindner, M.; Bugmann, H. |
editors | Vancura, K. |
publication type | Article |
publisher | Potsdam Institute for Climate Impact Research |
place of publication | Potsdam |
year | 1999 |
Starting by the first entry in our table:
Key | Value |
---|---|
label | Energy of the Biosphere |
The Label property is actually saved in the node itself, and does not create any connections to other nodes. We are going to use the label as the name of the node in the coming diagrams.
We can get the label by simply adding the string Label
at the end of the variable name:
#get all publications' labels
SELECT ?publicationLabel WHERE {
?publication P<instance of> Q<class: Work>
}
Going further in the entries, we have:
Key | Value |
---|---|
authors | Lindner, M.; Bugmann, H. |
editors | Vancura, K. |
There are two authors for this publication, as well as one editor.
Authors and Editor in our data model are both classes, and they both inherit from one base class: Creator.
The subclass
relationship between the classes has a transitive effect: every item that is instance of Author or Editor, is automatically an instance of Creator.
If we add our authors and editors to the model, we will have the following:
Using this information in a query:
#get all authors
SELECT ?author, ?authorLabel WHERE {
?author P<instance of> Q<class: Author>.
}
Note: it is also possible that an item is an instance of both Author and Editor.
#get all authors who are also editors
SELECT ?creatorLabel WHERE {
?creator P<instance of> Q<class: Author>.
?creator P<instance of> Q<class: Editor>.
}
So how does this connect with our example publication?
We define some additional properties (not to be confused with their respective classes):
-
author
: defines the author(s) of a publication -
editor
: defines the editor(s) of a publication
Using this information we can connect our example with the corresponding creators (the classes Author, Editor and Creator are omitted for clarity):
example queries:
#get all authors for a specific work: Energy of the Biosphere
SELECT ?author, ?authorLabel WHERE {
Q<Energy of the Biosphere> P<author> ?author.
}
#get all works by the author: Lindner, M.
SELECT ?work, ?workLabel WHERE {
?work P<author> Q<Lindner, M.>.
}
Going back to our entries:
Key | Value |
---|---|
publication type | Article |
To add this to our model, we introduce our publication type hierarchy (not the full list, omitted for clearness, see full list here)
Next, we use the publication type
property to connect the actual work with the corresponding publication type:
Example queries:
#get all works that are articles
SELECT ?work, ?workLabel WHERE {
?work P<publication type> Q<class: Article>.
}
#get all authors who wrote books
SELECT ?authorLabel WHERE {
?work P<publication type> Q<class: Book>.
?work P<author> ?author.
}
Further entries:
Key | Value |
---|---|
publisher | Potsdam Institute for Climate Impact Research |
place of publication | Potsdam |
We created base classes in our model for Publisher and Place of Publication, since the same Publisher can be responsible for multiple works, and multiple publications can be at the same place. (there are other base classes with the same purpose, see list here)
And then we connect the new items to our original example using the properties: publisher
and place of publication
(omitted some nodes for clarity):
And now for the last entry in our data:
Key | Value |
---|---|
year | 1999 |
We defined the property year
which accepts a literal, literals reside in the node, there are no new nodes created or connected when adding literal values.
Filling this into our diagram, we get the final state of the nodes:
This is one simplified example of our model, note that every node can be connected with other nodes, for example, the base class Work will have thousands of instances, an author can be connected to many of these instances, just like editors, publishers, etc.
To see the full data model, please refer to This page.