Re: [QB] ISSUE-29 Well-formedness

On 3 Mar 2013, at 15:51, Dave Reynolds wrote:
>>>   - deduction of some implicit rdf:type assertions from domain/range constraints
>> 
>> I would prefer not to reverse engineer RDFS entailment in SPARQL construct queries. Can we treat RDFS entailment as orthogonal to the Cube rules?
> 
> We certainly could.
> 
> My concern is that if we require readers to understand RDFS entailment in order to understand what a normalized Data Cube looks like then that might be scary.
> 
> In essence I just want to say that you can omit rdf:type statements on observations, slices and on dsd components that are referenced using the qb:dimension/qb:measure/qb:attribute properties.
> 
> My preference would be to include specific closure rules for those cases just to make it clear that those types may be omited, but to include a narrative note that they are implied by normal RDFS closure.
> 
> Would that be acceptable?

Yes.

>>>   - (possibly) deduction of default value for qb:componentRequired for any component which is not explicitly marked as optional (some details around measures on multi-measure cubes to sort here)
>> 
>> Hm, I never realized that the default for this property is "true". Would have preferred it to be "false". In other words, if it's not explicitly stated, then you cannot assume that it's required. Have to think more about this one.
> 
> My reading of the first bullet in 6.4 [1] is that we are saying if it is optional you must specify "false" which seems to imply that the default is true. However, it isn't clear - which is one reason for wanting to pin things down in closure rules :)
> 
> [1] https://dvcs.w3.org/hg/gld/raw-file/default/data-cube/index.html#dsd-dsd
> 
> I assume that "required" ought to be "true" for all Dimensions at least. We could have a default different for Dimensions than for Attributes but that might be confusing.

Hm. The text in 6.4 implies that qb:componentRequired is only for attributes anyways. This makes sense to me, and perhaps should be clarified further in the prose. I think it ought to say that qb:componentRequired is meaningless on component specifications for dimensions and measures.

That's because all dimensions *must* be defined for an observation for the observation to be meaningful, and measures can always be omitted anyway by simply not providing an observation.

I think making "false" the default value for componentRequired here has advantages. Most of all, it fits better with the general RDF philosophy that the value of something unsaid is unknown. It also means that no rule for inferring the default is required.

This also makes me think that componentRequired really ought to have been called attributeRequired...

>> I think a cube where a dimension is optional doesn't make any sense... So a well-formed cube should have componentRequired true for all dimensions.

(I was wrong here, see above. componentRequired doesn't really make sense on anything but attributes.)

Best,
Richard



>> Slice must have exactly one sliceStructure (modulo the other issue)
>> 
>> SliceKey must be connected to DSD
>> 
>> SliceKey components must be subset of the DSD's component
>> 
>> if A qb:slice B and B qb:observation C then C qb:dataSet A
>> 
>> qb:order on components within a dataset must be consecutive integers starting with 1
> 
> Good list, thanks.
> 
>> That's all I can think of at this time. Multi-measure cube stuff is still missing. If any of those things are hard to formalize in SPARQL, at least we should be really clear about the rule in prose.
> 
> Agreed.
> 
> Dave
> 
> 
>

Received on Sunday, 3 March 2013 20:00:12 UTC