These are properties that are calculated by some custom code, and not done by the usual matching. There are two provided now: applications are free to provide application-specifc ones.
- list:member - access the members of an RDF list.
- rdfs:member - access the members of rdf:Bag, rdf:Seq and rdf:Alt structures
Full Extension documentation
Normally, the unit of matching in ARQ is the basic graph pattern (a sequence of triple patterns). These sets of triple patterns are dispatched to Jena for matching by Jena's graph-level query handler. Each kind of storage provides the appropriate query handler. For example, the database fastpath is a translation of a set of triple patterns into a single SQL query involving joins.
There is also a default implementation that works by using plain graph find (a triple with possible wildcards) so a new storage system does not need to provide it's own query handler until it wants to exploit some feature of the storage.
If a function property is encountered, then it is internally treated as a call to be an extension. There is a registry of function properties to implementing code.
# Find all the members of a list (RDF collection)
PREFIX list: <http://www.jena.hpl.hp.com/ARQ/list#>
SELECT ?member
{ ?x :p ?list .
?list list:member ?member .
}
The functionality of list:member is handled by a class
in the extension library so this query is treated much like the ARQ
extension:
# Find all the members of a list (RDF collection)
PREFIX ext: <java:com.hp.hpl.jena.query.extension.library.>
SELECT ?member
{ ?x :p ?list .
EXT ext:list(?list, ?x)
}
where ext:list
is a function that bind its arguments
(unlike a FILTER function). The property function form is legal SPARQL.
So, this mechanism shows that collection access can be done in SPARQL without resorting to handling told blank nodes.
cwm (which is a forward chaining rules engine) and Euler
(which is a backward-chaining rules engine) already provide this style of access. Their property is
ARQ provides list:member to be like rdfs:member.
— Andy
2 comments:
Hi Andy,
Here is my understanding of property functions -
If I have a query like -
select ?x, ?y
where {
?x someProp1 SomeOb1
?y someProp2 SomeOb2
?x someLoc:propFunc ?y
}
the first and second lines bind x and y and the third line executes the function specified (someLoc:propFunc), instead of a regular pattern matching.
Is my understanding correct?
Please advice.
Pradeep
That's the compuational model. The execution engine can do anything provided it looks as if it happened that way. Property functions put a block on triple patterns being moved acorss them - the engine might execute the first two triple patterns in the other order, or concurrently but by thr time the property function is called, you can't tell.
Post a Comment