> On Nov 3, 2014, at 12:02 PM, Sergio Fernández <[email protected]> wrote: > > Hi Paul, > > On 03/11/14 14:24, Paul Danckaert wrote: >> First let me say that implementing an LD Client and Provider works quite >> well, and retrieving items by direct URI does work as expected, with the >> caching support and other normal capabilities. Once the item is cached, >> normal SPARQL queries are able to find the item based on it's URI or it's >> attributes, at least while it resides in the cache. > > Great! > >> I was curious, however, if there is any planned mechanism for retrieving >> items from the LD Client based on item attributes in some form instead of >> direct resource retrievals? For example, being able to do an LD Path query >> that would invoke the LD Client implementation to search on specific >> attributes, and return any matches to the query? I'm not sure what is in >> the road map for LD Client, so it would be interesting to see where it might >> be planned to go. > > Actually that's part of the complete design of the stack. And LDPath does use > of LDClient, via LDCache, while evaluating paths. > > In former times SPARQL did it too, but since the Sesame Sail is bypassed to > directly translate SPARQL into native KiWi SQL queries, we broke a bit the > original design and is not longer possible.
So I'm not totally sure if you mean that capability (querying on properties of items that are mapped via LD Client) is supported currently, or if that's in the plans for the future? In my DataProvider implementation I have retrieveResource returning a ClientResponse based on the resource identified explicitly. How would I extend that to support querying by attribute/relation values instead? In my example, if I had a set of buildings mapped via an LD Client provider, instead of retrieving by a building URI, could I retrieve all with a specific number of floors, or some other characteristic, and have my provider receive and process that request? > >> It may be that for maximum query flexibility the data should be propagated >> into Marmotta directly, but I'm still trying to consider data sources that >> are either too sizable or constrained, or perhaps just API driven and >> wouldn't be easily migrated. > > If you need specialized behaviors there, you can play blacklisting some URIs > (based on regex) or even providing specialized data providers to filter some > data. > > Hope that helps. I'm not sure how blacklisting some URIs would help with that, do you have any examples or specifics on that? Thanks for your help! paul
