search

w3c / dxwg

Data Catalog Vocabulary (DCAT)
https://w3c.github.io/dxwg/dcat/
Other
154 stars 47 forks source link

Profiles should contain constraint information #229

Open kcoyle opened 6 years ago

kcoyle commented 6 years ago

Application profiles should provide constraint information sufficient to validate instance data. (APs without constraint information cannot support validation services.)

This is a combination of issues 208, 210, 215

nicholascar commented 6 years ago

If a profile is defined in a "guidance" form only, e.g. expressed as a PDF doc only, then requiring constraint information will mean it can't be expressed in this ontology.

The G.A. example in the ontology, https://github.com/w3c/dxwg/tree/gh-pages/profiledesc/examples#geoscience-australia, does indicate a constraints version of the profile role: Conformance Test Constraints, but also the doc with role:Guidance and it is reasonable to expect many legacy profiles and profiles of things themselves not in Semantic Web form to only contain guidance docs.

dr-shorthair commented 6 years ago

@nicholascar That's why it says "should" rather than "must".

rob-metalinkage commented 6 years ago

There is are application profiles that can be conformance tested using formalised constraints - but others that require other approaches, or such constraints are not yet formed (such as DCAT-AP)

This is where implementation resources can be qualified with a specific role . The set of roles we wish to recognise and provide canonical terms for should be discussed - and whether these should be expressed as a class hiearchy, a skos:ConceptScheme - or both, and whether in a spearate artefact or the main ontology.

(I personally think a small class hierarchy within the OWL model is going to be simplest - and I would also be tempted to express SKOS semantic relationships. That way someone could easily define a skos:collection of the set of roles they wish to support in an application context)

nicholascar commented 6 years ago

Role qualification works well for me: I liked it in the ontology from the start

aisaac commented 6 years ago

I also like roles. And would have things to say on the discussion on how to model them in SKOS and OWL but this is not the place to discuss this ;-)

andrea-perego commented 6 years ago

I'm personally totally happy with "constraints" and I agree with @dr-shorthair . We are not saying that such constraints must be specified with a formal language. We just have to clarify this in the document.

I'm not sure about "roles": my feeling is that "constraint" is expressing the concept more clearly.

kcoyle commented 6 years ago

@nicholascar "If a profile is defined in a "guidance" form only, e.g. expressed as a PDF doc only, then requiring constraint information will mean it can't be expressed in this ontology."

To my mind, constraints do not have to be machine-actionable. The DCAT-AP includes cardinality and other constraints. To validate, a human would have to turn those stated constraints into some actionable code, but the constraints are still expressed in the AP. There is a plethora of metadata documentation in document form that is used (by humans) to create validation programs and "cross-walks" between metadata types. Although we should be moving into a more machine-actionable environment, our guidance document needs to include the current low-tech practices.

To whit, I see the guidance document having two threads:

  1. The concept of profiles and the information they contain (including why the information is useful)
  2. Some advice on practices that increase the utility and usability of profiles, like machine-readable vocabularies, presentation of validation schemas, etc.
nicholascar commented 6 years ago

There is a mechanism within the Profiles Ontology for giving resources within a profile a role (ResourceRole) and a role could be conformance and defined to be for machine-readable constraints. The example vocabulary of roles includes such terms.