Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Profiles should contain constraint information #229

Open
kcoyle opened this issue May 8, 2018 · 8 comments

Comments

Projects
None yet
6 participants
@kcoyle
Copy link
Contributor

commented May 8, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 8, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 8, 2018

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

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented May 9, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 9, 2018

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

@aisaac

This comment has been minimized.

Copy link
Contributor

commented May 9, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 17, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented May 18, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.