W3C home > Mailing lists > Public > public-lod@w3.org > December 2008

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

From: Georgi Kobilarov <georgi.kobilarov@gmx.de>
Date: Tue, 30 Dec 2008 12:29:26 +0100
Message-ID: <180C011CD4FF654AB4B73A9A5AD7472C0A4D65@aristoteles.zuhause.lan>
To: "Aldo Bucchi" <aldo.bucchi@gmail.com>, <public-lod@w3.org>

Hi Aldo,

How dynamic is ex:dynamic1? Does the value change for every request?
Can't you use caching? I'd say you should try to optimize your backend
instead of breaking conventions. Think of pre-computing all
rdf-documents and then serving static files, and updating them
periodically for example.

Best,
Georgi 

--
Georgi Kobilarov
Freie Universität Berlin
www.georgikobilarov.com

> -----Original Message-----
> From: public-lod-request@w3.org [mailto:public-lod-request@w3.org] On
> Behalf Of Aldo Bucchi
> Sent: Monday, December 29, 2008 4:51 PM
> To: public-lod@w3.org
> Subject: Granular dereferencing ( prop by prop ) using REST +
> LinkedData; Ideas?
> 
> 
> 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 Tuesday, 30 December 2008 11:30:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 30 December 2008 11:30:12 GMT