- From: Sarven Capadisli <sarven.capadisli@deri.org>
- Date: Fri, 06 Dec 2013 13:10:13 +0100
- To: Benedikt Kaempgen <kaempgen@fzi.de>, Dave Reynolds <dave.e.reynolds@gmail.com>
- CC: Government Linked Data Working Group <public-gld-wg@w3.org>
On 07/15/2013 01:54 PM, Dave Reynolds wrote: >> Note that simply resolving URIs is not enough anyway. Unless you have >> slices or your URIs resolve to provide incoming as well as outgoing >> links (in which case you are going to get some *really* big result >> pages). You would need to do it via a SPARQL endpoint. I agree. But, there is a but: it is partly "Linked Data friendly". If a QB or VoID dataset - which I generally think that they describe the same resource - is discovered, one should be able to follow their nose to each of the observations. Is this currently possible via qb:observationGroup and qb:observation? (Sorry, I haven't looked at these properties closer before) So, at some point it comes down to: http://www.w3.org/2012/ldp/track/issues/33 It is an interface problem. Whether there is an HTML or an RDF representation, how do we reasonably let the consumer reach to each observation? Under normal circumstances, the consumer should probably get to the bulk of the dataset through discovering qb:DataSet or void:Dataset. When this is not possible for non-trivial datasets, applications end up resorting to SPARQL - which is not necessarily a "bad" thing, but still can be a PITA in comparison to dereferencing. On 11/26/2013 06:58 PM, Benedikt Kaempgen wrote: > In general, however, I think that a SPARQL endpoint should not be a > necessity to get all data for a QB dataset. In case the number of > observations is too large, slices can be used to split observations > into several resolvable uris; in case the number of observations is > reasonable, the incoming qb:dataSet links - in my opinion - should be > returned with the dataset URI. Creating slices on datasets with a lot of observations, and no existing slices is a lot of work :'( And even still, the problem doesn't go away with slices, as they would still point to a lot of observations. Alternative is to have many slice groups but I think that just shifts the problem to another place. > Unfortunately, not all datasets (e.g., Linked SDMX Data by Sarven > [2]) are doing this, currently. If you mean there is no link from a qb:DataSet to each of its own qb:Observations, that's true. But, there are slices in some 270.info datasets. Can you clarify? Is there a particular dataset you are looking at or are you only referring to the Linked SDMX implementation? Would you mind creating an issue https://github.com/csarven/linked-sdmx if there is a fundamental problem with the transformation? Much appreciated! -Sarven http://csarven.ca/#i
Received on Friday, 6 December 2013 12:10:46 UTC