W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > May 2018

Re: Requirements for Profile Guidance

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Sun, 27 May 2018 23:34:40 +0200
To: <public-dxwg-wg@w3.org>
Message-ID: <f796a95c-6170-0b0b-db49-f2f998aac58e@few.vu.nl>
Hi Karen,

OK now I understand, thanks!

Antoine

On 23/05/18 07:47, Karen Coyle wrote:
> Antoine, as I understand what we decided at F2F3, we are re-extracting
> the requirements that in the current UCR are listed under "Profile
> Definition", or 6.1. The new ones that we extract and approve would
> replace the ones in the current UCR. The motivation is that when we went
> to reach consensus on the requirements (2 separate times) people didn't
> understand where the requirements had come from, with #212 being such a
> case.
> 
> This does not mean that the requirements in the Google Doc are complete.
> They are my first pass and are open to revision, addition, etc. However,
> it is important that the requirements derive directly from the use cases.
> 
> Short answer: Once new requirements are extracted and approved, we will
> close the ones currently in github.
> 
> kc
> 
> On 5/22/18 11:17 PM, Antoine Isaac wrote:
>> Hi Karen, all,
>>
>> I have one extra request for clarification on the google doc. Recently
>> (after F2F3) there have been new requirement-like issues created, for
>> example:
>> https://github.com/w3c/dxwg/issues/212
>> https://github.com/w3c/dxwg/issues/228
>> https://github.com/w3c/dxwg/issues/229
>> I understand that even if they look like reasonable requirements, these
>> should not be considered in the discussions around the google doc
>> because the connection with the use cases is not as direct as what
>> you've started. Am I right?
>>
>> Cheers,
>>
>> Antoine
>>
>> On 21/05/18 08:11, Karen Coyle wrote:
>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>>
> 
Received on Sunday, 27 May 2018 21:35:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:44:59 UTC