Consider using separate property URIs for each component property subclass

[csarven]

Currently using a single property path for component property URIs e.g., http://{authority}/property/{version}/{conceptSchemeID}/{conceptID}.

Since the main component properties can be one of: qb:DimensionProperty, qb:MeasureProperty, or qb:AttributeProperty, consider using dimension, measure, or attribute instead of property in path.

Advantages: as the property URIs are constructed by reusing the conceptScheme/concept information, it is possible that the same pattern is used for multiple component properties e.g., dimension and attribute, which results in having the same resource with qb:DimensionProperty and qb:AttributeProperty. Therefore, having different paths would avoid this conflict.

Disadvantages: single path like property is simpler. Also, anonymous users of the data will complain about this change. But, .. ohwell.

This is not a bug per se, but I'm tagging it as such because the potential of having multiple classes for the same resource is there.

[cygri]

Another disadvantage: Need more namespace declarations for queries.

I'm on the fence about this. Separating the three kinds of properties is cleaner, but the complexity piles up.

[csarven]

It sucks to have these three kinds of fugly property URIs but I think we are rather forced to create them - considering the source format and automating. In Linked SDMX, we construct these unique property URIs by re-using the information from the SDMX Component (and what it refers to). Since the concepts are versioned and may or may not be part of a concept scheme, we have to throw them in there to distinguish from other properties. We also have to treat the type of property component it is the same way. Although slightly different, we had to make a similar decision on creating distinct concept URIs. If we don't foster this distinction, the consequence is that we have information loss, something de-normalized, and not really semantically uplifted in the end.

Having said that, I would rather resolve this issue like this:

• The implementation should default to constructing three kinds of properties
• Configuration to let the user to override the default with their preferred namespace(s) for any of the properties. Existing issues deal with this: Extend configuration for URI construction and patterns #38 , Configuration to map dimension, measure, or attribute values to use a prefered namespace #42 , Configuration to use SDMX-RDF URIs directly #34.

This might be a happy middle (or quite possibly the over-engineered version) especially if the data owner is aware of the possibility of ending up with properties with different intentions. Therefore, they can decide between the options (default, or something simplified) that's suitable for them.

[der]

Not sure I know enough about the context here to be helpful ...

Strictly dimension, measure and attribute properties are supposed to be disjoint[1]. So if there's a chance the same concept can play multiple roles then you probably ought to use the more complex pattern. That's the approach we took with the SDMX COG translation.

Yes it is slightly more complex to query. If you are manually curating a DSD design you would put the properties in the same namespace for convenience. But with automated translations it is probably best to err on the side of separation - the URIs are going to be ugly anyway :)

Configurations options can be good or bad. They can make a system more complex, be a source of support issues and lead to too much variation for the poor data consumers. But one user's confusion is another's welcome flexibility.

[1] By which I mean they are declared as owl:disjoint, so the intent is clear. In practice you could overlap them and still be able to generate and query the data from SPARQL just fine. You are unlikely to use an OWL reasoner on this sort of data. But some cube validator and visualizer software may rely on the disjointness so that they know a property will only play one role and use that in their implementation.