Re: Granular dereferencing ( prop by prop ) using REST + LinkedData; Ideas?

Hi Aldo,

Aldo Bucchi wrote:
> I am in the process of LODing a dataset in which certain properties
> are generated on the fly ( props derived from aggregate calculations
> over the dataset, remote calls, etc ). I would like to let the clients
> choose which of these expensive properties they need on demand and on
> a granular level.

I came across a similar problem the other day where responses are also generated on the fly and some of the values require remote calls - the problem here is that those calls might keep you waiting or even time out. Not good for those who are more interested in the data you provide yourself.

> The problem is that the value for ex:dynamic1 is very expensive to
> compute. Therefore, I would like to "partition" the document in such a
> way that the client can ask  for the property on a lazy, deferred
> manner ( a second call in the future ).
> The same is true for dynamic2, dynamic3, dynamic4, etc. All should be
> retrievable independently and on demand.

Is it really necessary to partition it on the property level or can you group things together? Is the caller interested in only having certain properties (in that case they would probably use your SPARQL endpoint instead anyway) or are they just interested in keeping the cost of the call below a certain level while getting as much interesting stuff as possible?

> * I am also aware that most solutions require us to break URI
> obscurity by stuffing the subject and predicate in the uri for a doc.

Constructing URIs isn't always a bad thing, URI templates [1] might help with that. From a REST point of view linking to new states is of course better. Do people program their clients towards your service or do you expect generalised LOD clients without any previous knowledge of your service?

> * Finally, seeAlso is too broad as it doesn't convey the information I need.

I think it's a strong enough predicate in that scutters [2] will generally follow it.

I would probably put the properties into query variables if you want to keep it really flexible and allow the client to really only request those properties they're interested in. But that means the client has to have previous knowledge of your service to know how to construct the URIs.
For general LOD clients I would provide links to a handful of documents which group those expensive properties together in a sensible way. You could come up with a vocabulary that describes the cost of accessing those documents(*). Since I think this is a problem that will appear more often in the future such a vocabulary might get established and integrated into general LOD clients.

Regards,
  Simon

[1] http://bitworking.org/projects/URI-Templates/spec/draft-gregorio-uritemplate-03.html
[2] http://wiki.foaf-project.org/Scutter
(*) This is similar to FOAF+SSL where you'd want to say that a linked document is private and can only be accessed with certain authentication methods. Or giving a GRDDL client hints what sort of transformation document/service to expect. So the client has this knowledge about linked documents *before* it tries to access them.

Received on Tuesday, 30 December 2008 13:09:54 UTC