- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 1 Jan 2009 12:19:20 +0100
- To: Aldo Bucchi <aldo.bucchi@gmail.com>
- Cc: "public-lod@w3.org" <public-lod@w3.org>
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