- From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
- Date: Sun, 08 Nov 2009 22:33:00 +0100
- To: public-rdf-dawg@w3.org
On Saturday 7. November 2009 04:12:03 Lee Feigenbaum wrote: > > This very use case was mentioned very early in the game as something > > several people wanted to have: > > http://www.w3.org/2009/sparql/wiki/Feature:LimitPerResource > > and, if I remember correctly, the champions for that use case (Alex, > > Kjetil) settled their fights for this feature purely on the > > observation that it would be doable with subselect. Yeah, reluctantly, as Steve said in the F2F1 something like "trust me, this is going to be simple enough to do, we need it too". > This is not limit per resource. Limit per resource is... sort of the > opposite. It's retrieving 10 people with all of their names, even if > some of them have more than 1 name. Yup, that's correct. The requirement is based on how we sell RDF solutions, what we say is that it makes no sense to use RDF if your schema is well known and changes rarely. RDF shines if you have a situation where you have a resource, with written by some number of authors, some of which have different names they are known under, works for several organisations, and some things may be known about them, but not the same thing as about others. Further, the resource may be classified with one or more skos:Concepts, out of which some may be linked to DBpedia, others are not. It turned out that it was rather painful to limit the number of results you get when querying such data since you have no idea how many solutions that are of interest, but that limit was essential to get decent response times. Cheers, Kjetil -- Kjetil Kjernsmo kjetil@kjernsmo.net http://www.kjetil.kjernsmo.net/
Received on Sunday, 8 November 2009 21:33:39 UTC