Some remarks about the current documentation "Zazuko Document 09 December 2021"

[FabianCretton]

Here I give my remarks about the current document version ""Zazuko Document 09 December 2021".
Nothing "major", I hope it can help to clarify a few things

Typo:

• https://zazuko.github.io/rdf-cube-schema/#dimensions
  "All Observations need to provide " -> why having the 's' of 'Observations' formatted differently ?
  This is the case a few times in the whole document.

• https://zazuko.github.io/rdf-cube-schema/#usage-of-code-lists
  "Dimensions that point to objects like code lists (i.e taxonomies represented in vocabularies like SKOS Simple Knowledge Organization System Primer can be expressed as well:"
  There is a missing closing ")"

• https://zazuko.github.io/rdf-cube-schema/#Relation
  "A Cube:Relation resource is used to express the relation between different dimensions, the nature of the relationship is determined by the properties used. a Cube:Relation is linked"
  -> capital 'a'

To be clarified/proposals:

• Abstract:
  Why is "Abstract" part of https://zazuko.github.io/rdf-cube-schema/#issue-summary and why it doesn't have a paragraph numbering and anchor ?

• https://zazuko.github.io/rdf-cube-schema/#dimensions
  "It has to be ensured that properties are not attached at the wrong level. Spatial dimensions for example are most likely not attached to the observation directly but to an instance of a dimension referenced in the observation."
  Give more context, explain why they are "most likely not attached"

• https://zazuko.github.io/rdf-cube-schema/#usage-of-code-lists
  "Dimensions can have further types, which are not defined by this vocabulary to support other Dimensions (e.g. Precision, Statistical Measures) or for additional Attributes to filter on, which are not part of the key to defining a cube:KeyDimension."
  Introduces for the first time the notion of cube:KeyDimension -> add a link to the related explanation https://zazuko.github.io/rdf-cube-schema/#cube-keydimension

• Issue 40
  https://zazuko.github.io/rdf-cube-schema/#issue-container-number-40
  Title proposal "Constraint extensions", as the descriptions says " it is possible to extend the Constraints".
  Maybe add "Constraint extensions (to facilitate cube usage for Visualizations, etc.)"

• https://zazuko.github.io/rdf-cube-schema/#cube-shareddimension
  About Shared Dimension, would it be correct to say that Shared Dimensions are the way to do "Linked Data" with the cube. And explain why, what is the idea behind that new "Shared Dimension" concept instead of just linking to resources of another dataset.

• https://zazuko.github.io/rdf-cube-schema/#properties-0
  Give a little introduction, maybe "Here are the expected properties to be defined for the instances of a dimension class".

• https://zazuko.github.io/rdf-cube-schema/#qudt-scaletype
  "To provide more information on the statistical property of the scale of measure is described by qudt:NominalScale, qudt:OrdinalScale, qudt:IntervalScale or qudt:RatioScale which is attached through qudt:scaleType to the Cube Constraint per Dimension."
  The link for "Cube Constraint per Dimension" should certainly be updated to point to a paragraph inside that same document.
  Then I am not sure that the beginning of the sentence really makes sens " To provide more information on the statistical property of the scale of measure is described by" ?

• https://zazuko.github.io/rdf-cube-schema/#meta-datakind-temporal-spatial
  "Finally to express that the dimension provides a specific kind of data which is necessary to select the correct visual representation"
  Remove "Finally", as there is now another paragraph under this one.

• https://zazuko.github.io/rdf-cube-schema/#meta-datakind-temporal-spatial
  " we add https://cube.link/meta/dataKind/ with the following structure possible values:"
  Is the terme "structure" to be removed here or does it make sense ?

• https://zazuko.github.io/rdf-cube-schema/#version-history-of-cubes
  Shouldn’t there be a mention about schema:version ?
  The SPARQL query opened from a Cube Creator publication is for instance:

    <https://environment.ld.admin.ch/foen/fab_OFPP_POC_sheltersbasicdata> schema:hasPart ?cube .
      ?cube schema:version 1 .

• https://zazuko.github.io/rdf-cube-schema/#existing
  Just a small remark: the paragraph is named "Existing Work", does not mean a lot when reading the table of content, could be "Relative Work" or even better ""Relative Work analysis" ?

[IsabelMeraner]

some additional remarks from my side. just a few small things, overall I think it's great and really helpful, thanks!

prefixes:

• external namespaces to be added to overview: geo (geosparql), skos, xsd
• internal prefix to be added: relation

general best practices:

• make more explicit that translations should always be realized with schema:name (and not rdf:label):
  schema:name "Room 1101"@en, "Raum 1101"@de, "Pièce 1101"@fr ;
• add a warning that without dimension schema:name no labels will be displayed in web apps such as viz-tool
• add info on general IRI best practices / templates: eg. no hash uri should be used, etc. maybe the following template structure could be an example?

# cube
  <[NAMESPACE]/[CUBE_ID]/cube/[VERSION_NO]> 
# observation set
  <[NAMESPACE]/[CUBE_ID]/cube/[VERSION_NO]/observation/> 
# observation
  <[NAMESPACE]/[CUBE_ID]/cube/[VERSION_NO]/observation/[OBS_ID]> 
# constraint
  <[NAMESPACE]/[CUBE_ID]/cube/[VERSION_NO]/constraint>  

2.4.1.3 other properties:

• clearly distinguish between mandatory and non-mandatory properties on cube-level, change the sentence "you are free to add other properties related to your Cube or the publication process of your Cube directly on the instance of the Cube."
• make it explicit, which dimensions are mandatory for the vis-tool, for instance add a link to the required dimension for the visualization tool (eg. schema:creativeWorkStatus)
• also list possibilities for cube-level properties other than schema:name, schema:description (for clarity, they are partially already listed in section on extension viz-tool or advanced topics):

cube:observationSet
cube:observationConstraint
schema:contactPoint
schema:Dataset
schema:contributor
schema:creativeWorkStatus
schema:creator
schema:dateCreated
schema:datePublished
schema:dateModified
schema:publisher
schema:version
schema:workExample
schema:expires

missing image:

• "Our example can be visualized: Example of a hierarchy"

Standard error:

• use standardError as dimension name instead of precision

PREFIX relation: <https://cube.link/relation/>
[ 
  sh:path <dimension/precision>  # should be standardError not precision
  # ... additional definitions for that sh:property
  meta:dimensionRelation [ 
    # We use a Class to indicate the e.g. the standard error.
    a relation:StandardError ;
    # A generic cube metadata property points to the relevant dimension.
    meta:relatesTo ex:dimension\/measurement;
  ]
]

[semanticfire]

@IsabelMeraner the open tasks of your comment relate more to the specific requirements of viz-tool and not so much to the core rdf cube schema vocabulary.
The finished tasks are incorporated in the working document