Re: ISSUE-69 (IC-8 Errata): Typo in IC-8 rule [Data Cube Vocabulary]

We need to decide how to handle this issue. Please could the chairs add 
this to the agenda for the next meeting.

My advocacy is that we regard this as a non-substantive error:
    o the intent of the rule is clear
    o the published query will work for the normal case where a single 
Data Cube is being checked for well-formedness
    o all current implementation reports are unchanged if we correct the 
rule
    o we have precedent with ISSUE-68 of accepting a similar scale of 
change without a process reset

If this is a reasonable argument then I would like a formal working 
group resolution to this effect.

If we think this change is not acceptable then we would need to decide 
whether to proceed without IC-8 (the integrity check section is marked 
at risk in such a way that we could withdraw the rule entirely).

Dave


On 02/11/13 19:00, Government Linked Data Working Group Issue Tracker wrote:
> ISSUE-69 (IC-8 Errata): Typo in IC-8 rule [Data Cube Vocabulary]
>
> http://www.w3.org/2011/gld/track/issues/69
>
> Raised by: Dave Reynolds
> On product: Data Cube Vocabulary
>
> There is a typo in the SPARQL query used to implement integrity check IC-8 (http://www.w3.org/TR/vocab-data-cube/#ic-8) in the Data Cube specification.
>
> The published query is:
>
>      ASK {
>        ?slicekey a qb:SliceKey;
>            qb:componentProperty ?prop .
>        ?dsd qb:sliceKey ?sliceKey .
>        FILTER NOT EXISTS { ?dsd qb:component [qb:componentProperty ?prop] }
>      }
>
> However, the second occurrence of ?slicekey is mis-typed as ?sliceKey making it a different variable.
>
> For a data set comprising a single data cube, the normal case, this has no effect. There will be only one match to ?dsd (the Data Structure Definition) and the check will work. However, in cases where there are multiple data cubes with different DSDs within the same graph then the rule will incorrectly fail.
>
> This does not affect any reported implementation conformance results.
>
>
>
>

Received on Saturday, 2 November 2013 19:12:01 UTC