-----BEGIN PGP SIGNED MESSAGE-----
Those interested in these questions (caching, indexing, etc. in the LD context) and who are of a technical background might find instructive the work done on the Apache Stanbol (a descendent of the EU IKS effort) EntityHub project:
This is a software component for a larger semantic framework that attacks some of these problems, providing (cached) retrieval, management and (text- or triplestore-based) indexing of LD entities. It's by no means a solution in itself to these problems, but it's useful to me to examine how other people have approached them in concrete ways, and what they did or didn't find difficult in practice.
The University of Virginia Library
On Sep 3, 2013, at 5:47 AM, Wallis,Richard wrote:
> Caching is both easier and more challenging in the Linked Data environment.
> For direct access to a URI, the web infrastructure takes care of most of it. If implemented correctly at the server end, the caches will be made aware if the information behind a URI has changed (e.g. a death date added to an authority) and will update itself. Even if a server is not operating that way, web caches will refresh in a time based mode ensuring a near real-time up to date view.
> The challenge of local storage/indexing will require rethinking of some of the approaches we have to come to rely upon.
> Take the [overly] simple case of a Work with a title, an author and a subject. The Work description will contain three bits of information - a string "The Title" and two URIs: a VIAF URI for the author; a LCSH URI for the subject. To build a subject index or an author index we need to get the data from somewhere else other than where the Work data came from.
> Keeping things up to date in this environment is just plain different - you will get no indication from the source of the Work that VIAF has added a death date for the author. These challenges could have many answers - download a copy and regularly update a copy of VIAF, LCSH, etc., etc. - use remote indexes - check in the background (using the web) each of theURIs you use to see if the indexing data has changed - and combinations thereof.
> All of this is important "It is not the model but without it the model won't work in real life", but is separate from the data model and vocabulary. Which is why we should consider a parallel implementation(s) guide which would help draw some of the technology specific debate away from confusing the modelling and vocabulary discussion. Bibframe is still a good forum for both.
> My 2 cents….
> On 3 Sep 2013, at 06:03, Shlomo Sanders <[log in to unmask]> wrote:
>> I agree with your sentiment.
>> There are 2 primary ways of using Linked Data
>> - Just In Time access baed on the URI. For example, AJAX based display in a user interface.
>> This scenario has me less worried.
>> - Just In Case local caching. This is mandatory for data to be locally indexed for search purposes. This case is more problematic because of the challenges of keeping the local cache up to date. The more LD you use the more it becomes an issue.
>> If the community, as a community, would implement a push mechanism of updates that is appropriate to Linked Data this would be a big help. A good example could be community acceptance of ResourceSynch, Unfortunately this is another case of Chicken and the Egg. Most do not create a Client listener if there aren't enough Servers. Most do not create Servers if there aren't enough Clients. Around and around we go.
>> One way out of this cycle is explicitly recommending a specific solution as part of the BF framework. It is not the model but without it the model won't work in real life (at least not if we want to gain enough advantages to warrant implementing BF). This may be arguable, but it is my opinion.
>> Sent from my iPad
>> On Sep 2, 2013, at 20:10, "J. McRee Elrod" <[log in to unmask]> wrote:
>>> Perhaps there could be notification if there is change in the authority,
>>> say a death date added?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
-----END PGP SIGNATURE-----