Closed prototypo closed 10 years ago
Support for SPARQL Property Paths would allow much more flexibility in the template language.
For example, this would support OPTIONAL Alternatives. SPARQL allows one to preferentially select one of a list of optional values, like this:
OPTIONAL { ?annoAuthor foaf:name ?annoAuthorName . } OPTIONAL { ?annoAuthor rdfs:label ?annoAuthorName . }
The second OPTIONAL block for ?annoAuthorName will only be matched if the first one fails. This SPARQL would be generated from template language by use of property paths, e.g.:
<span rel="oa:annotatedBy" resource="?annoAuthor"> By: <a href="{?annoAuthor}">{foaf:name|rdfs:label}</a> </span>
Copy any property paths provides in CURIEs into the generated SPARQL. We would not support embedded relative URIs (in angle brackets).
Support for SPARQL Property Paths would allow much more flexibility in the template language.
For example, this would support OPTIONAL Alternatives. SPARQL allows one to preferentially select one of a list of optional values, like this:
OPTIONAL { ?annoAuthor foaf:name ?annoAuthorName . } OPTIONAL { ?annoAuthor rdfs:label ?annoAuthorName . }The second OPTIONAL block for ?annoAuthorName will only be matched if the first one fails. This SPARQL would be generated from template language by use of property paths, e.g.:
<span rel="oa:annotatedBy" resource="?annoAuthor"> By: <a href="{?annoAuthor}">{foaf:name|rdfs:label}</a> </span>Copy any property paths provides in CURIEs into the generated SPARQL. We would not support embedded relative URIs (in angle brackets).