Why only qb:AttributeProperty can be optional?

[Jindřich Mynarz]

Hi,

I'm wondering why only qb:AttributeProperty can be optional; i.e. have qb:componentRequired [1] set to false. I can guess but I'd appreciate a link to the discussions that led to this decision during the development of the Data Cube Vocabulary.

If I'm not mistaken, this restriction was introduced in March 2013 (https://github.com/UKGovLD/publishing-statistical-data/commit/6b39304116f3eb1b0b3b45109dcb57dc14c0adf2#diff-8e91b20a53c7050dcc57c56725100a99R290). For example, the Payments Ontology developed in 2010 (http://data.gov.uk/resources/payments) on the basis of QB still contained the notion of optional dimension (payment:expenditureCategory). I've looked into archives of the Government Linked Data Working Group mailing list archives (https://lists.w3.org/Archives/Public/public-gld-wg/) for February and March 2013 and into the GLD's issue tracker (http://www.w3.org/2011/gld/track/issues/), but I couldn't find a thread related to this decision. Does someone remember why qb:componentRequired was decided to be this way?

Best,

Jindřich

[1] Why it's qb:componentRequired and not qb:attributeRequired if it can be applied only to qb:AttributeProperty? Similarly, if it can be applied only to qb:AttributeProperty, why its rdfs:domain is the more generic qb:ComponentSpecification?

-- 

Jindřich Mynarz

http://mynarz.net/#jindrich

[Dave Reynolds]

Hi Jindřich,

On 17/05/15 09:08, Jindřich Mynarz wrote:
> Hi,
>
> I'm wondering why only qb:AttributeProperty can be optional; i.e. have
> qb:componentRequired [1] set to false. I can guess but I'd appreciate a
> link to the discussions that led to this decision during the development
> of the Data Cube Vocabulary.
>
> If I'm not mistaken, this restriction was introduced in March 2013
> (https://github.com/UKGovLD/publishing-statistical-data/commit/6b39304116f3eb1b0b3b45109dcb57dc14c0adf2#diff-8e91b20a53c7050dcc57c56725100a99R290).

Not really. It was always the case that dimensions and measures were
required, that goes back to the original SDMX model.

The commit you are pointing to was to do with implementing the integrity
checks including those that enforced that (IC-6,11,14). The change to
the comment on qb:componentRequired was intended to be clarifying only.

> For example, the Payments Ontology developed in 2010
> (http://data.gov.uk/resources/payments) on the basis of QB still
> contained the notion of optional dimension
> (payment:expenditureCategory).

Not sure I follow, payment:expenditureCategory is a dimension and is
required. It says on that page:

"The individual expenditure lines include at least net cost (netAmount)
and an associated expenditureCategory ..."

> I've looked into archives of the
> Government Linked Data Working Group mailing list archives
> (https://lists.w3.org/Archives/Public/public-gld-wg/) for February and
> March 2013 and into the GLD's issue tracker
> (http://www.w3.org/2011/gld/track/issues/), but I couldn't find a thread
> related to this decision. Does someone remember why qb:componentRequired
> was decided to be this way?

It was part of the original SDMX-derived model and so predates the
working group.

You could argue that it would be useful to allow optional measures in
the case of multi-measure cubes but I don't see how it could make sense
to have an optional dimension. The set of dimensions define what the
observation applies to. If you don't have one of the dimensions then you
don't have an observation you only have partial information about an
observation. You could represent that using slices or you could have a
non-well-formed cube.

Dave

[Jindřich Mynarz]

Hi Dave,

thank you for the clarification. That's probably the most authoritative answer I could have got.

On Sun, May 17, 2015 at 12:22 PM, Dave Reynolds <dave.e....@gmail.com> wrote:

The commit you are pointing to was to do with implementing the integrity checks including those that enforced that (IC-6,11,14). The change to the comment on qb:componentRequired was intended to be clarifying only.

I see. 

For example, the Payments Ontology developed in 2010
(http://data.gov.uk/resources/payments) on the basis of QB still
contained the notion of optional dimension
(payment:expenditureCategory).

Not sure I follow, payment:expenditureCategory is a dimension and is required. It says on that page:

"The individual expenditure lines include at least net cost (netAmount) and an associated expenditureCategory ..."

I've probably misinterpreted the diagram (http://data.gov.uk/sites/default/files/ontology%20payment-diagram-simple.png) the description of which says: "Consequently, there is a minimal mandatory structure, highlighted using the bold lines in the diagram, and optional properties which can be omitted if the information is not available for publication." payment:expenditureCategory edge isn't bold, so I concluded that it's an optional dimension.

It was part of the original SDMX-derived model and so predates the working group.

You could argue that it would be useful to allow optional measures in the case of multi-measure cubes but I don't see how it could make sense to have an optional dimension. The set of dimensions define what the observation applies to. If you don't have one of the dimensions then you don't have an observation you only have partial information about an observation. You could represent that using slices or you could have a non-well-formed cube.

I'm not arguing in favour of optional dimensions. I was only confused by the Payments Ontology, which seemed to have optional dimensions. That led me to think that the concept of required qb:DimensionProperty was introduced to the Data Cube Vocabulary later. I was interested in the discussion about this decision and I wondered if there actually were any good reasons of having optional dimensions. However, as you pointed out, this was adopted directly from SDMX.

Thanks again for the explanation.

- Jindřich

[Dave Reynolds]

Hi Jindřich,

> For example, the Payments Ontology developed in 2010
> (http://data.gov.uk/resources/payments) on the basis of QB still
> contained the notion of optional dimension
> (payment:expenditureCategory).
>
>
> Not sure I follow, payment:expenditureCategory is a dimension and is
> required. It says on that page:
>
> "The individual expenditure lines include at least net cost
> (netAmount) and an associated expenditureCategory ..."
>
>
> I've probably misinterpreted the diagram
> (http://data.gov.uk/sites/default/files/ontology%20payment-diagram-simple.png)
> the description of which says: "Consequently, there is a minimal
> mandatory structure, highlighted using the bold lines in the diagram,
> and optional properties which can be omitted if the information is not
> available for publication." payment:expenditureCategory edge isn't bold,
> so I concluded that it's an optional dimension.

You are right it does. Strictly that's an error, at least a payments
data set without categories wouldn't be a well-formed cube with respect
to the full payments DSD.

My only excuse is that the payments ontology was done while the ink was
still very wet on the first draft of the Data Cube vocabulary. We were
still getting the hang of things.

The way to repair this would be to have a second reduced DSD for
minimally detailed payments datasets.

Dave

[Sarven Capadisli]

On 2015-05-17 12:22, Dave Reynolds wrote:
> Hi Jindřich,
>
> On 17/05/15 09:08, Jindřich Mynarz wrote:
>> Hi,
>>
>> I'm wondering why only qb:AttributeProperty can be optional; i.e. have
>> qb:componentRequired [1] set to false. I can guess but I'd appreciate a
>> link to the discussions that led to this decision during the development
>> of the Data Cube Vocabulary.
>>
>> If I'm not mistaken, this restriction was introduced in March 2013
>> (https://github.com/UKGovLD/publishing-statistical-data/commit/6b39304116f3eb1b0b3b45109dcb57dc14c0adf2#diff-8e91b20a53c7050dcc57c56725100a99R290).
>>
>
> Not really. It was always the case that dimensions and measures were
> required, that goes back to the original SDMX model.

AFAICT, SDMX 2.x states all of the components as optional (minimum
occurrence of 0). Of course, that is practically useless as far as RDF
Data Cube or anyone is concerned.

I do not know the rationale / discussions (if any) which went into the
original QB comment, but I can see that leaving the qb:AttributeProperty
optional would be "okay". The qb:MeasureProperty's value can be typed
with XSD (or other) which would be sufficient to qualify the values.

Attachments higher up on the structure are the only reason/place I can
think of where leaving out the components may be okay.

Slightly off topic, but relevant for the next release of QB (*):

QB takes a subset of SDMX 2.0. SDMX is currently at 2.1 which has some
important distinctions/improvements. IIRC, one important aspect which
I've noticed was that, SDMX 2.1 is far more clear about explicitly
associating attribute(s) with measure(s). If I'm not mistaken, in QB, we
can't tell right now which attribute goes with which measure.

* At some point, I'll create issues based off the Linked SDMX effort.

-Sarven
http://csarven.ca/#i