ProfileRoundup
!! WARNING !! This page was created to jump start the profiles guidance document. It is not being kept up to date and should only be viewed as historical. Current requirements are in the UCR document and current discussions are in github with the label profile-guidance.
This is a page that gathers decisions, discussions, and requirements that will inform the Profile Guidance document. There is no "new" content here. For discussion of these topics, please use github issues.
Profile definitions and examples
Proposed Application Profile Guidance document outlines
- Notes and outline from f2f3
- Proposal for the structure of the "Guidance for Application Profiles" document #196
- profileDesc and the Guidance document #242
- Phil's suggested introduction
Proposed profile description models
AP Guidance and Validation
Various discussions
- Profiles should contain constraint information
- A profile must be packaged as a self-contained artifact
- Are inference rules constraints that must be followed by profiles?
- Web browser navigation of profile information
- Definition of "Formalism"
- Definition of "Schema" (as opposed to profile)
- Use standard for profile identification
- Profile Composition and Languages
Approved requirements
!! WARNING !! This page was created to jump start the profiles guidance document. It is not being kept up to date and should only be viewed as historical. Current requirements are in the UCR document and current discussions are in github with the label profile-guidance.
- Requirement: Profiles are "named collections of properties" or metadata terms (if not RDF) [ID41] (5.41) [profile] APPROVED (GitHub 275)
- Requirement: Profiles may provide rules on cardinality of terms (including “recommended”) [ID41] (5.41) [profile] APPROVED (GitHub 276)
- Requirement: Profiles may provide rules governing value validity [ID41] (5.41) [profile] APPROVED (GitHub 277)
- Requirement: Profiles may express dependencies between elements of the vocabulary (if A then not B, etc.) [ID41] (5.41) [profile] APPROVED (GitHub 278)
- Requirement: Profiles may be written in or may link to a document or schema in a validation language (ShEx, SHACL, XMLschema). [ID41] (5.41) [profile] (GitHub 279)
- Requirement: There needs to be a property in the profile where the rules for the descriptive content can be provided. This would apply to the entire profile. [ID42] (5.42) (GitHub 255)
- Requirement: Profiles should be able to indicate what external standards specifications are expected to be applied/have been applied to the data provided.[ID43] (5.43) APPROVED (GitHub 280)
- Requirement: Profiles can have what is needed to drive forms for data input or for user display. [ID46] (5.46) [profile] APPROVED (GitHub 281)
- Requirement: Profiles can have rules for data value validation, including pick lists [ID46] (5.46) [profile] Suggested re-writing as per Action-127: "Requirement: Profiles may provide lists of values to pick from in order to populate data elements [id46] (5.46) [profile]" APPROVED (GitHub 282)
- Requirement: Profiles can have human-readable definitions of terms and input instructions [ID46] (5.46) [profile] APPROVED (GitHub 283)
- Requirement: "Profiles may add to or specialise clauses from one or more base specifications. Such profiles inherit all the constraints from base specifications.” [ID37] [ID39] (GitHub 212)
- Requirement: a vocabulary or data model can be a profile of several other vocabularies or data models at once (GitHub 268)
- RPFDF: Create a way to list the profiles implemented by a dataset or a specific distribution (GitHub 73)
(Accepted in principle, but needs rewording. Some suggested wordings:
- A profile can be based on several data models or vocabs at the same time
- A profile can be dependent several vocabularies or data models at the same time
- A profile can be dependent on several vocabularies or data models at the same time
- a profile can have multiple base specifications