schema.datacommons.org: issues noted at (pre-alpha) launch

[danbri]

This meta issue tracks known issues for the https://schema.datacommons.org/ vocabulary and its relationship with the dataCommons Knowledge Base (dCKB).

Technical issues relating to the underlying site software are better recorded at schema.org; we are using an early version of the schema.org code designed to support external schema extensions.

These initial schemas, and the associated data model, should be considered pre-alpha.

• We need to clarify how and when to use different properties for the same underlying concept, for example if different datasets had related but significantly different enumerations.
• the underlying KG has a rich notion of provenance for every data item, but this could map to graph vocabulary (and APIs) in several ways. In terms of vocabulary we can use constructs such as "sub-property" and dataset-specific enumerations, and are looking at how best to apply Schema.org's notion of an "external enumeration", as well as looking at other relevant approaches (e.g. StatDCAT, SPARQL named graphs, Data Cube, PROV, etc.). W3C's CSVW, as well as Wikidata's data model and its mapping to their query service, are also both relevant.
• Need to clarify how to handle documentation for schema.org terms where dataCommons is re-using rather than introducing new terms, but is nevertheless adding significant additional constraints, usage guidance or where there are dataset-related code lists, footnotes/caveats, etc.
• Although this vocabulary is not being proposed for general schema.org-like (markup) use, it would help to show more examples in the site.
• Need style guideline / syntax rules for dataset-qualified terms, especially enumerations.
  • Syntactically "/" is appealing (e.g. "/USC/35To44Years" but "/" in term URLs affects browser behaviour when loading relative links ("docs/foo", for CSS, JS etc.). There may be mismatches with the naming style from the dcKG graph, which can initially be resolved with a 404 handler but need eventually to be alligned.
• These schema definitions need to be imported into the dcKG graph itself (including some portion or all of latest Schema.org)