-
Notifications
You must be signed in to change notification settings - Fork 15
Models
The [LODSPeaKr templating system](Templating system in LODSPeaKr) comprises model queries that feed view templates.
Model queries are stored in the $LODSPEAKR_HOME
/components directory. This page describes how model queries can be organized in this directory to achieve a variety of effects.
Models queries are structure in a file hierarchy. This allow users to use multiple queries to serve one specific URI. For example, while one query obtains a person's name and age, another query can lists her friends.
- Use all lower case (cross-OS compatibility)
- Do not use dashes (b/c of Haanga)
- Can use underscores
- Files must end with
.query
extension, otherwise they won't be executed.
The Type Component (see Modules) provides a workflow of queries for URIs of a certain type (e.g., foaf:Person
, void:Dataset
, etc.).
LODSPeaKr needs to know about the namespace used in the URI. For example, the namespace foaf
is defined by default (along with several others) in namespaces.php
file. You can add more namespaces (or override existing ones) by including in settings.inc.php
$conf['ns']['prefixName'] = 'http://new/namespace/to/be/used/';
To create a model for a specific type in LODSPeaKr users need to execute in the lodspeakr
directory the following command:
utils/lodspk.sh create type foaf:Person
This will create directory following the naming convention for models instead of using just a file. The structure of the directort will look like this:
# This is a "types" component (could have been "services" or "uri")
# The rdf:type that this type component applies to
components/types/foaf:Person/
|-> queries/
|-> sp.query # SPARQL Query
|-> po.query # SPARQL Query
You can add more queries at the same level as main.query
(for example, listing friends of the person, in friends.query
). LODSPeaKr will run all the queries inside the directory html.queries
. In the template view, each result will be available as models.main
, models.friends
, etc..
components/types/foaf:Person/
|-> queries/
|-> sp.query # SPARQL Query
|-> po.query # SPARQL Query
|-> main.query # SPARQL Query
|-> friends.query # SPARQL Query
In the example above, the query results will be available in the template view as models.main
and models.friends
, as shown below. See How to use results for more details.
{%for row in models.main%}
{{row.name.curie}} and {{row.age.value}} # The attributes 'name' and 'age' are SPARQL SELECTed
{%endfor%}
{%for row in models.friends%}
{{row.firstlastname.curie}} and {{row.lastname.value}}
{%endfor%}
Extending the use of multiple queries, it may be desirable to use external URIs to retrieve more information that may be available in other data sources (we are talking about Linked Data after all).
To do this, add additional endpoint shortnames in settings.inc.php
. By default, LODSPeaKr includes a reference to DBpedia and LOGD's endpoints.
$conf['endpoint']['dbpedia'] = 'http://dbpedia.org/sparql';
$conf['endpoint']['logd'] = 'http://logd.tw.rpi.edu/sparql';
Thus, it is possible to include queries to different data sources by extending the directory structure.
components/types/foaf:Person/
|-> queries/
|-> sp.query # SPARQL Query
|-> po.query # SPARQL Query
|-> main.query # SPARQL Query
|-> friends.query # SPARQL Query
|-> endpoint.dbpedia/ # Indicates the use of 'dbpedia' endpoint
|-> dbpediaQuery1.query
|-> dbpediaQuery2.query
|-> endpoint.logd/ # Indicates the use of 'logd' endpoint
|-> logdQuery1.query
|-> logdQuery2.query
LODSPeaKr will execute the queries in a breadth-first search (so far there is no order or queries in the same directory but that may change). One way to force a specific order is to create a new directory called local
and include the query file there. For example, if we want to force that mail
will be queried first then friendsoffriends
we can specify the following structure:
components/types/foaf:Person/
|-> queries/
|-> sp.query # SPARQL Query
|-> po.query # SPARQL Query
|-> main.query # SPARQL Query
|-> friends.query # SPARQL Query
|-> endpoint.local/ # Indicates the use of local endpoint AFTER previous queries
|-> friendsoffriends.query # SPARQL Query
In the same way that we can use {{uri}}
in any model query, the results of a model's prior queries can also be used in its subsequent queries. The syntax to [access the results](How to use results) in nested model queries is the same as in view templates.
For example, if we want to query dbpedia using their URI (assuming we have our URI linked to it via owl:sameAs
). We create the following structure:
components/types/foaf:Person/
|-> queries/
|-> sameas.query # This file contains a SPARQL query to submit
|-> endpoint.dbpedia/ # Use 'dbpedia' endpoint
|-> info.query # SPARQL query
The model query sameas.query
would contain:
SELECT ?dbpediaUri WHERE{
<{{uri}}> owl:sameAs ?dbpediaUri .
}
while the model query info.query
would contain:
SELECT ?p ?o WHERE{
<{{first.sameas.dbpediaUri.value}}> ?p ?o.
}
The same ideas can be applied when retrieving data using the URI Module (see Modules for more information). To create a file structure for a particular URI, you need to execute in the lodspeakr
directory, the following command:
utils/lodspk.sh create uri local:foobar
where local:foobar
is the URI (in CURIE format) that has to be matched. The file structure created will be similar to the one for types. It is also possible to create workflows of execution and use external SPARQL endpoints as well:
components/uris/local:Alvaro/
|-> queries/
|-> sameas.query # This file contains a SPARQL query to submit
|-> endpoint.dbpedia/ # Use 'dbpedia' endpoint
|-> info.query # SPARQL query
- Creating components in LODSPeaKr for an introduction
- Examples how to use haanga in lodspeakr
-
Example: How to set up a class
- Type priority to resolve model selection when an instance's types match multiple criteria.
- Example: How to set up a uri
- Example: How to set up a service
- Introduction-to-Content-Negotiation
- Proposal-for-naming-convention-in-models-and-views for a potential redesign on naming.
- How to use results to obtain values from prior model queries in subsequent model queries.
- Views to specify the templates in which model query values are placed.