Re: AW: AW: Discovering QB observations (Was: Re: ORG browser)

Nice! Thanks for the feedback, Benedikt.

Okay, so, I would say that WB and TI are sort of these annoying 
exceptions. They predate Linked SDMX so some of the metadata stuff 
(e.g., VoID) are not generated automagically. I do some hand-holding on 
them.

Having said that, if you look all of the dataspaces' /well-known/void 
they do have a void:dataDump. There is no individual void:dataDump per 
void:Dataset i.e., http://ecb.270a.info/dataset/EXR doesn't, however it 
available from one level higher http://ecb.270a.info/dataset/ecb , which 
is also a void:Dataset pointing at http://ecb.270a.info/dataset/EXR and 
others with void:subset.

Same idea with the other dataspaces e.g., 
http://fao.270a.info/dataset/fao , 
http://worldbank.270a.info/dataset/world-bank-finances , 
http://transparency.270a.info/dataset/corruption-perceptions-index (BTW, 
you probably caught me at a time when I was switching over to 
http://transparency.270a.info/dataset/CPI2011 from 
http://transparency.270a.info/dataset/corruption-perceptions-index/2011 ) :)

As far as VoID goes, that's the general setup. I'm not claiming that 
that's the best approach, but AFAIK that's "fine". In any case, I think 
you are right that it would be nice to have each void:Dataset point at 
its own RDF dump file. Certainly makes more sense and friendlier. After 
all, they are all available under /data/ . Will take care of that :)

Well noted Andreas Harth's seeAlso suggestion (also based on in-person 
discussion with him) :)

PS: I've made a commit for your heads-up on the blank nodes for 
components. I just have to re-transform stuff :)

-Sarven

On 12/12/2013 05:45 PM, Benedikt Kaempgen wrote:
> Hi,
>
> Thanks, Sarven!
>
> Regarding providing the observations via void:dataDump (or similar).
>
> Some of your datasets do not provide this, e.g. [1-4].
>
> Also, I am wondering whether only a zipped (e.g., [6] for dataset [5]) data dump is possible. For applications that do not know about un-packing of files, would it not be nicer if lookups would directly provide RDF?
>
> If there is a SPARQL endpoint providing those triples, Andreas Harth suggested to provide "seeAlso" links to URIs containing SPARQL CONSTRUCT queries on the SPARQL endpoint such as [7] (could also be partitioned into smaller chunks).
>
> Best,
>
> Benedikt
>
> [1] <http://fao.270a.info/dataset/CAPTURE>
> [2] <http://worldbank.270a.info/dataset/world-bank-finances/sfv5-tf7p>
> [3] <http://transparency.270a.info/dataset/corruption-perceptions-index/2011>
> [4] <http://ecb.270a.info/dataset/EXR>
> [5] <http://worldbank.270a.info/dataset/world-bank-climates>
> [6] <http://worldbank.270a.info/data/world-bank-climates.tar.gz>
> [7] ---------------------
> construct {?obs ?p ?o}
> where {
>
> ?obs a qb:Observation.
> ?obs ?p ?o.
> }
> -------------------------
>
>
> ________________________________________
> Von: Sarven Capadisli [sarven.capadisli@deri.org]
> Gesendet: Samstag, 7. Dezember 2013 18:03
> An: Benedikt Kaempgen; Richard Cyganiak
> Cc: Dave Reynolds; GLD Working Group (Government Linked Data)
> Betreff: Re: AW: Discovering QB observations (Was: Re: ORG browser)
>
> On 12/07/2013 04:49 PM, Benedikt Kaempgen wrote:
>> Hello,
>>
>> Thanks for your thoughts.
>>
>>> Tell me if I’m wrong, but I’m not aware of any use of QB that relies on the kind of dataset-to-(slice-to-)observation navigation that you describe.
>>
>> Since in the Linked Data Cubes Explorer [1] we rely on resolveable URIs, I am looking for recommendations of how to fetch all relevant content for a qb:DataSet.
>>
>>   From the discussions, I see the following possibilities that the application should try:
>>
>> * Resolving the dataset URI also returns blank nodes of observations including their outgoing links such as to the dataset or dimension values.
>> * Resolving the dataset URI returns incoming links from observation URIs that can be resolved, separately, to retrieve their outgoing links.
>> * Resolving the dataset URI returns outgoing links to slices, that in turn link to either blank nodes of observations with their outgoing links or to observation URIs that can be resolved for their outgoing links.
>> * Resolving the dataset URI returns outgoing links void:sparqlEndpoint or void:dataDump that lead to RDF representations of all observations.
>>
>>> 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!
>>
>> Thanks, Sarven. If your datasets provide one of the above possibilities to reach the observations via lookups that is great.
>>
>> Not related to observations but metadata: If I only want to crawl the metadata of your datasets, however, I see a problem with blank nodes.
>>
>> For instance, dataset http://oecd.270a.info/dataset/HEALTH_STAT links to its structure http://oecd.270a.info/structure/HEALTH_STAT that however only links to blank nodes of components but does not return their outgoing links. Can you tell me how I would find such outgoing links?
>
>> Best,
>>
>> Benedikt
>>
>> [1] <http://www.ldcx.linked-data-cubes.org:8000/ldcx-trunk/ldcx/ld-cubes-explorer.html>
>
> You are right about the metadata. This is my bad. It should move away
> from blank nodes. Historically it is due to following along the
> convention that is used in the QB spec examples.
>
> So, unfortunately, you have to use SPARQL to get to them at the moment.
> I've created an issue:
>
> https://github.com/csarven/linked-sdmx/issues/35
>
> will resolve and republish for *.270a.info
>
> I think that might just be the last group of blank nodes. Minus the
> LODStats stuff..
>
> Thanks.
>
> -Sarven
>

Received on Saturday, 14 December 2013 16:37:00 UTC