Re: [QB] Implementation report

Hi Sarven,

Thanks very much for the implementation report which I've added to the 
tracking page at [1].

I understand the challenge of automatically assigning a suitable 
rdfs:range.  Note that you could duck this test by assigning a vacuous 
range such as rdfs:Resource :)

Dave

[1] 
http://www.w3.org/2011/gld/wiki/Data_Cube_Implementations#Conformance_reports

On 04/12/13 11:00, Sarven Capadisli wrote:
> I would like report a Data Cube implementation.
>
> http://www.w3.org/2011/gld/validator/qb/qb-test?upload=upload-2013-12-04T09-16-44-56
>
>
> Failed 4
>
>
> An sample from an IMF dataset is used: http://imf.270a.info/dataset/DM
> with accompanying metadata.
>
> IC4 (i.e., every Dimension must have a declared range) works as
> expected. For what its worth, a bit about the implementation and why
> that particular test fails, and why I'm letting it fail for the time being:
>
> The implementation is based on SDMX-ML to RDF/XML transformation (
> Source: https://github.com/csarven/linked-sdmx , Documentation:
> http://csarven.ca/linked-sdmx-data ). The transformation effort keeps
> its assumptions minimal about the data and metadata. One particular
> example from the failure is that the source TimeDimension from the
> SDMX-ML KeyFamily for IMF DM doesn't mention a code list that it is
> using. When the code list information is available, it is used towards
> writing triples about qb:codeList and rdfs:range. Having said that, the
> the time dimension value from the SDMX-ML DataSet is "sniffed" to
> determine whether to use a suitable URI (e.g., British reference
> periods) or not in the data. At this time, this information is only used
> in the DataSet transformation, and not the DSD.
>
> The range information can be derived from TimeDimension's concept
> reference. However, such concepts don't particularly help in the end as
> most of the time (based on my own observations) they only consist a
> label. I think a good-enough solution would be to use that concept for
> the range any way, and then later have a mapping from that concept to a
> vocabulary which the data ends up using.
>
>
> I realize that most of this information is probably irrelevant for
> testing the spec, but I wanted to type it out any way. It essentially
> points out that we need to have more heuristics built into the
> transformations [at least for Linked SDMX] in order to have a
> well-behaving data in QB.
>
> :)
>
> -Sarven
> http://csarven.ca/#i
>

Received on Wednesday, 4 December 2013 15:32:19 UTC