Re: Requirements for Profile Guidance

hi -

what is the provenance of these (proposed?) requirements?

They seem to heavily overlap with a combination of the requirement 6.8.1
Profile definition [RPFDF]  and the sort of constraint language
requirements we would expect (noting that specific constraint languages may
be varied and are agreed to be out of scope).  I can't immediately identify
anything obviously not covered, but if any new requirements exist we should
certainly discuss and if agreed add them to the UCR, or improve the current
UCR wording ASAP

Are we best of splitting out the individual clauses in 6.8.1, which
represent the current consensus position into separate requirements,
creating git hub issues, and then seeing if all these suggestions are in
fact covered (i.e. i think the onus would be to line up the specific
proposal against the relevant existing clauses and provide an example of
where a a new functional requirement is indicated,  or a better explanation
for an existing one)

Note that I have also proposed a DCAT-AP inspired profile publishing Use
Case to bring together the implications and existing practices around
Profile Guidance into a more familiar context.

I think this would also allow us to check these specifics, again I dont yet
see any additional requirements, but there is obviously a need for better


On 20 May 2018 at 16:57, Karen Coyle <> wrote:

> These are the requirements that I have identified that, based on the use
> cases, are related to profile guidance. IMO these are fairly
> unremarkable and fit into the outline that we developed at the F2F[1].
> These requirements can be viewed in the context of their use cases in
> the Google Doc.[2]
> Profile requirements
> Requirement: Need a way to express compatibility between profiles [ID37]
> (5.37)  [profile]
> Requirement: Profiles are "named collections of properties" or metadata
> terms (if not RDF) [ID41] (5.41) [profile]
> Requirement: Profiles may provide rules on cardinality of terms
> (including “recommended”) [ID41] (5.41) [profile]
> Requirement: Profiles may provide rules governing value validity [ID41]
> (5.41) [profile]
> Requirement: Profiles may express dependencies between elements of the
> vocabulary (if A then not B, etc.) [ID41] (5.41) [profile]
> Requirement: Profiles may be written in or may link to a validation
> language (ShEx, SHACL, XMLschema). [ID41] (5.41) [profile]
> Requirement: Profiles should be able to indicate what external standards
> are expected to be applied to the data provided. [ID42] (5.42) [profile]
> Requirement: Profiles should be able to indicate what external standards
> are expected to be applied/have been applied to the data provided.[ID43]
> (5.43)
> Requirement: Profiles can have what is needed to drive forms for data
> input or for user display. [ID46] (5.46) [profile]
> Requirement: Profiles can have rules for data value validation,
> including pick lists [ID46] (5.46) [profile]
> Requirement: Profiles can have human-readable definitions of terms and
> input instructions [ID46] (5.46) [profile]
> Requirement: Profiles may be coordinated with validation schemas. [ID48]
> (5.48) [profile]
> (They don't come out numbered here, so we will look at the google doc in
> order to refer to numbering.)
> kc
> [1]
> Gks5dDa8n2B5IN6rWa3kRpo/edit#heading=h.cuvn3apl2413
> [2]
> GxSCFQV1aWtOPg/edit#heading=h.5l26dadqk5v7
> --
> Karen Coyle
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600

Received on Sunday, 20 May 2018 23:43:13 UTC