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

Clarify PROF's relation to constraint languages #721

Open
nicholascar opened this issue Jan 31, 2019 · 4 comments

Comments

@nicholascar
Copy link
Contributor

commented Jan 31, 2019

Leslie Sikos wrote:

By reading the specification, the relationship with SHACL remains somewhat unclear, and it is mentioned mainly in the context of implementations only, while the PROF ontology aims at setting constraints as well.

@nicholascar nicholascar added this to the PROF 2PWD milestone Jan 31, 2019

@nicholascar nicholascar self-assigned this Jan 31, 2019

@nicholascar nicholascar added this to To do in Profiles Ontology via automation Jan 31, 2019

@nicholascar

This comment has been minimized.

Copy link
Contributor Author

commented Jan 31, 2019

PROF does not set any constraints itself; it only presents a way of describing Profile relations (to Standards and perhaps other Profiles) and profile components (via prof:ResourceDescriptors). PROF leaves to constraint languages in general, of which SHACL is one, to specify particular constrains for particular profiles.

An example: If Profile X of Standard Y imposed additional constraints on it and those constraints were presented using SHACL, you may have prof:Profile and prof:ResourceDescriptor RDF like this:

<Profile_X>
    rdf:type prof:Profile ;
    rdfs:label "Profile X" ;
    prof:isProfileOf <Standard_Y> ;
    prof:hasResource _:1 .

_:1
    rdf:type prof:ResourceDescriptor ;
    rdfs:label         "Profile-only constraints in SHACL" ;
    dct:conformsTo     <http://www.w3.org/ns/shacl#> ; # SHACL
    dct:format         <https://w3id.org/mediatype/text/turtle> ;
    prof:hasRole       role:ExtensionConstraints ;  # these constraints are in addition to the Standard Y constraints and does not include them
    prof:hasArtifact   <an_rdf_file_on_the_web.ttl> .

So <an_rdf_file_on_the_web.ttl> here contains SHACL Shapes graphs for use with this Profile but the profile description itself, this RDF, does not.

If this answers the question, where should a version of this be included in PROF? Alignments as a Note?

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2019

@nicholascar I think a better example would be simply to a constraints resource, not "additional constraints". Also, I note that "extensionConstraints" has been added to the list of roles but I don't think the working group discussed or agreed on that change.

@andrea-perego

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2019

I wonder whether this issue relates somehow to the more general question of which languages can be used for "profiles", and for doing what. This is actually more in scope with the profile guidance document, and I take this opportunity to ask again if it may be worth including an appendix listing the existing languages and their capabilities - something along the lines of the draft in

https://docs.google.com/spreadsheets/d/1Zty4jTzhG0_1xoJlDOMq1XeHelIwVP2-STw6_-_ZxR4/edit#gid=0

We did something similar in the Spatial Data on the Web Best Practices, by listing the existing "formats" for geospatial data, and showing which of them comply with which best practice(s), to help people make a choice based on their requirements - see

https://www.w3.org/TR/sdw-bp/#applicability-formatVbp

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Feb 8, 2019

@andrea-perego I take your point, and wonder if the use of "constraints" in PROF and in the role vocabulary needs more guidance on what is considered validation/constraint. As it is today, PROF doesn't contain much in the way of guidance, and the defintions of terms are quite concise. Perhaps this is not sufficient.

Profiles guidance will include a section on constraints and constraint languages, but it will probably speak to a braoder defintion that can include non-actionable constraint declarations such as those in DCAT-AP's PDF document.

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.