On Tuesday 03 August 2010, Nathan wrote:
> Aldo Bucchi wrote:
> > Hi Ivan, Jorn,
> >
> > I've run into similar requirements. A catch-all solution to this could
> > be to surface the ability to specify a custom deref procedure
> >
> > define input:iri_deref "DB.DBA.MY_CUSTOM_IRI_DEREF"
> >
> > This should get all the context to decide whether to perform a fetch
> > and also have access to the sponger infrastructure.
> >
> > This is a broad and raw idea, I know. The point is that the current
> > visibility into what happens under the covers is too low. Of course,
> > in an ideal world, sources should play along with the Linked Data
> > rules ( including specifying caching TTL ) but in reality you might
>
> and ETag's!
>
> > want to override some sources, implement specific caching strategies,
> > etc.
> >
> > Spongers provide some flexibility in the "how do I get stuff from a
> > IRI" part. But perhaps the controller part could also be "extensible".
>
> FWIW, +1 unless you can simply designate sponger to use a proxy, which
> would solve all use cases from what I can tell.
Yupp, I definitely agree. AFAIK there currently is no possibility to make use
of let's say a local DBpedia mirror in case you're using the IRI-dereferencing
options:
If I use:
DEFINE get:proxy "localhost:8890"
with this query:
DEFINE input:grab-all "yes"
DEFINE input:grab-depth 1
SELECT DISTINCT ?p ?lp ?o ?lo
WHERE {
<http://dbpedia.org/resource/Barack_Obama> ?p ?o.
OPTIONAL { ?p rdfs:label ?lp. }
OPTIONAL { ?o rdfs:label ?lo. }
}
I'm told that get:proxy only makes sense with a FROM clause. So is there any
possibility to use a proxy (e.g., the current datastore's URL rewriting) for
IRI dereferencing, or perhaps even Aldo's suggestion of a special
DB.DBA.MY_CUSTOM_IRI_DEREF ?
Cheers,
Jörn
