Re: Requirements for Profile Guidance

Oh, and I should add that the Google Doc [1] shows each requirement in
the context of its use case (the lower part of the doc), so if there are
questions about wording we can go back to the use cases. I tried to
mimic the language in the use case, but that wasn't always possible.
Also, I selected the use cases marked as "Profile" but struck out ones
that seemed to be covered as DCAT requirements. That's all in the Doc,
along with some comments of mine. And if anyone wants to comment on the
Doc, do so but you may need to remind us before/during the meeting to
look for your comments there.

kc
[1]
https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/edit

On 5/21/18 7:09 AM, Karen Coyle wrote:
> The profile guidance requirements would replace 6.8.1, which we have
> failed to vote on now despite two attempts. At the F2F it was decided to
> re-extract the requirements, keeping a clear relationship between
> requirements and use cases.
> 
> Some of the content negotiation requirements also appeared in 6.8.1,
> which may have led to some of the confusion. The use cases there pretty
> clearly speak about negotiation.
> 
> Note that none of the requirements in 6.8.1 have ever been approved by
> the group, so this is new work and should help us scope both of the
> deliverables.
> 
> kc
> 
> On 5/21/18 1:42 AM, Rob Atkinson wrote:
>> 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.
>>
>> https://github.com/w3c/dxwg/issues/238
>>
>>
>> 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 communication.
>>
>> Rob
>>
>>
>>
>> On 20 May 2018 at 16:57, Karen Coyle <kcoyle@kcoyle.net
>> <mailto:kcoyle@kcoyle.net>> 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]
>>     https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks5dDa8n2B5IN6rWa3kRpo/edit#heading=h.cuvn3apl2413
>>     <https://docs.google.com/document/d/15OfNXU9AJ-cZysc7uYP-Gks5dDa8n2B5IN6rWa3kRpo/edit#heading=h.cuvn3apl2413>
>>     [2]
>>     https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/edit#heading=h.5l26dadqk5v7
>>     <https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/edit#heading=h.5l26dadqk5v7>
>>     -- 
>>     Karen Coyle
>>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>>     m: 1-510-435-8234 (Signal)
>>     skype: kcoylenet/+1-510-984-3600
>>
>>
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Monday, 21 May 2018 06:12:00 UTC