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

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


Aldo,

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:
http://simile.mit.edu/mail/ReadMsg?listName=Linking%20Open%20Data&msgId=20926

And some refinements here:
http://simile.mit.edu/mail/ReadMsg?listName=Linking%20Open%20Data&msgId=20962

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:
http://esw.w3.org/topic/SeparateDocumentsForLongPropertyLists

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:
http://simile.mit.edu/mail/ReadMsg?listName=Linking%20Open%20Data&msgId=20930
http://simile.mit.edu/mail/ReadMsg?listName=Linking%20Open%20Data&msgId=21015

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  
consensus.

All the best,
Richard



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
>
> PRIVILEGED AND CONFIDENTIAL INFORMATION
> 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.
> INFORMACIÓN PRIVILEGIADA Y CONFIDENCIAL
> 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