Passing arguments to services
Sometimes is desirable to create new URIs for documents that provides information about multiple resources: For example, a list of people can be described as a set of URIs, one for each person. However, there is no way to find information about all of them.
In LODSPeaKr this is possible by creating a service
http://BASEHOST/SERVICENAME/ARG1/ARG2/...
To access each parameter, you can use {{lodspk.args.arg0}}, {{lodspk.args.arg0}}, etc. To access the whole string, you can use {{lodspk.args.all}}.
Please check Example: How to set up a service. Also, check how parameters change when you are Creating services with slashes
For example, components/services/myService/queries/main.query will generate an HTML file with a list of instances for a certain type
SELECT DISTINCT ?resource WHERE {
?resource a {{lodspk.args.arg0}} .
}
For example, http://server/myService/rdfs:Class will generate the query
SELECT DISTINCT ?resource WHERE {
?resource a rdfs:Class .
}
(LODSPeaKr will provide the necessary prefixes in case it doesn't exist.)
In order to avoid a null value, you can always use the default filter to provide a default value.
SELECT DISTINCT ?resource WHERE {
?resource a {{lodspk.args.arg0|default:"owl:Class"}} .
}
will add owl:Class if no value is provided.
The parameters can be used at the template level as well:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" {% for i, ns in base.ns %}xmlns:{{i}}="{{ns}}"
{%endfor%}version="XHTML+RDFa 1.0" xml:lang="en">
<head>
<title>Instance of {{base.args.arg0}}</title>
<link href="{{lodspk.baseUrl}}/lodspeakr/css/basic.css" rel="stylesheet" type="text/css" media="screen" />
</head>
<body>
<h1>Instances of {{lodspk.args.arg0}}</h1>
<ul>
{% for row in r %}
<li><a href='{{ row.resource.value }}'>{{row.resource.curie}}</a></li>
{% endfor %}
</ul>
</body>
</html>
It is clear that the approach here is different from 'regular' resources: In that case, the information is obtained after an 303 HTTP redirect, because everything is considered a non-information resource. On the other hand, for special URIs, everything is considered an information resource (a document) so no redirection is required. Moreover, the documents that describe a NIR are different depending on the format delivered: This was a conscious decision to make easier for the consumer to know what will she receive (it is easier to look at the extension than check the HTTP header). For special URIs, this is not the case, so the same URI can be implemented to return multiple formats. While I'm fine with this for now, I can imagine there may be reasons to change this, however I haven't found them yet. Of course, it is perfectly possible to create different special URIs that only serve one format (creating files like special.mydata.json.json.html and special.mydata.json.model.json)