W3C home > Mailing lists > Public > public-lod@w3.org > January 2009

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

From: Richard Cyganiak <richard@cyganiak.de>
Date: Thu, 1 Jan 2009 12:19:20 +0100
Cc: "public-lod@w3.org" <public-lod@w3.org>
Message-Id: <BEBCE3B9-7BB4-4196-8DB1-781B40EB6BDB@cyganiak.de>
To: Aldo Bucchi <aldo.bucchi@gmail.com>

Happy new year to all LODers! 2009 will certainly be another  
interesting year around here!


The issue you describe below has been discussed in a long thread back  
in 2007. We mostly talked about a slightly different problem -- where  
a resource description would include a very large number of values for  
a particular property -- and therefore we want to move those triples  
into a separate document that is somehow reachable from the resource  
description. But a solution to that problem would likely also solve  
your problem (you have just a single value for the property but it's  
expensive to compute and should therefore be retrieved in a separate  
HTTP call).

I proposed this solution:

And some refinements here:

This is actually based on some side comments that TimBL made in his  
original Linked Data document -- I think he saw this problem coming.

I started a page on the ESW wiki back then:

There was no real conclusion to the thread, and no formal proposal was  
written up, just a problem statement. That's because we couldn't  
really reach consensus. Others were pushing for a more flexible and  
complex solution than the one I describe in the links above. See here  
-- it's the “arcs” proposal:

I wonder what people think about this issue now, and if we can get  
closer to a workable proposal. I'm willing to spend some cycles on the  
writeup and preparing the vocabulary if we can reach some rough  

All the best,

On 29 Dec 2008, at 16:51, Aldo Bucchi wrote:

> Hi All,
> 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.
> For example, lets say I am interested in knowing more about resource
> <http://ex.com/a>.
> Per LD conventions, dereferencing http://ex.com/a ( via 303 ) returns
> <http://ex.com/a> a ex:Thing ;
>  rdfs:label "a sample dynamic resource";
>  ex:dynamic1 45567 .
> 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.
> * I am aware that this can be achieved by extending SPARQL in some
> toolkits. But I need LOD.
> * 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.
> * Finally, seeAlso is too broad as it doesn't convey the information  
> I need.
> Anyone came up with a clean pattern for this?
> Ideas?
> Something as simple as:
> GET http://x.com/sp?s={subject}&p={predicate} ---> required RDF
> works for me... but... .
> If possible, I would like to break conventions in a conventional  
> manner ;)
> Best,
> A
> -- 
> Aldo Bucchi
> U N I V R Z
> Office: +56 2 795 4532
> Mobile:+56 9 7623 8653
> skype:aldo.bucchi
> http://www.univrz.com/
> http://aldobucchi.com
> This message is only for the use of the individual or entity to  
> which it is
> addressed and may contain information that is privileged and  
> confidential. If
> you are not the intended recipient, please do not distribute or copy  
> this
> communication, by e-mail or otherwise. Instead, please notify us  
> immediately by
> return e-mail.
> Este mensaje está destinado sólo a la persona u organización al cual  
> está
> dirigido y podría contener información privilegiada y confidencial.  
> Si usted no
> es el destinatario, por favor no distribuya ni copie esta  
> comunicación, por
> email o por otra vía. Por el contrario, por favor notifíquenos  
> inmediatamente
> vía e-mail.
Received on Thursday, 1 January 2009 11:20:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:15:54 UTC