Re: Plenary agenda June 5

Those are either content negotiation or profile description (as in the
profileDesc proposal from Rob and Nick). It still isn't clear to me
where the functionality belongs, and in some cases it may be both.

I had divided up the requirements on the G-Doc into two sets: content
negotiation and profile guidance. Some WG members commented that my
grouping of content negotiation was not accurate as some of those
requirements would not be fulfilled by content negotiation, but would be
fulfilled by metadata that describes the profile. If I am not mistaken,
there are WG members who view the profile guidance document as being
primarily or solely related to profile description metadata, not as a
description of the functionality of profiles themselves. In the github
issue on the possible outline of the guidance document,[1] I have
suggested a document in two parts: 1) guidance on the functions of
profiles (terms, cardinality, etc.) 2) a model for the description of
profiles (possibly based on profileDesc). That's there for discussion,
but isn't a group decision at this point.

My gut feeling is that it will be easier to agree on the second set of
requirements, #s 12-24. The first set has the issues of whether each is
part of content negotiation or profile description, and it gets us into
the question of inheritance again, which seems to be a difficult point
for the group.


On 6/4/18 12:22 PM, Annette Greiner wrote:
> items like:
>  1.
>     Requirement: Clients should be able to determine which profiles are
>     supported by a server, and with which content types.  [ID2] (5.2)
>     [conneg]
>  2.
>     Requirement: There should be a way for a client to look up
>     additional information about a profile. (What kinds of information?
>     Can we clarify this?)  [ID2] (5.2) [conneg]
> On 6/4/18 12:13 PM, Karen Coyle wrote:
>> Ah, those are the ones that I see as being requirements for profiles,
>> and that would be included in the Guidance document where it talks about
>> the functionality of profiles. I read them as being "these are the
>> things a profile needs to have to be a profile". So we may be in sync on
>> that. Now, which are the ones that are "these are the things the spec we
>> are writing needs to accomplish"?
>> kc
>> On 6/4/18 11:31 AM, Annette Greiner wrote:
>>> some examples:
>>>   * 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 can have rules for data value validation,
>>>     including pick lists [ID46] (5.46) [profile]
>>> On 6/2/18 12:17 AM, Karen Coyle wrote:
>>>> I'm not sure which ones you see as requirements for a spec. Can you give
>>>> a couple of examples?
>>>> My take is that as we were developing the use cases most of them were
>>>> about requirements for profiles, not requirements for a profile guidance
>>>> document. And we would take those requirements for profiles and turn
>>>> them into a guidance document.
>>>> kc
>>>> On 6/1/18 9:06 PM, Annette Greiner wrote:
>>>>> Are these supposed to be requirements as in
>>>>>   "these are the things the spec we are writing needs to accomplish"
>>>>> or requirements as in
>>>>>   "these are the things a profile needs to have to be a profile"?
>>>>> To me, the requirements listed on the agenda read as the latter, which
>>>>> are the contents of a spec (e.g., they use terms like "can" and "may"),
>>>>> but other requirements in the GDoc read as the former, which are
>>>>> requirements for a spec.
>>>>> -Annette
>>>>> On 6/1/18 6:54 AM, Karen Coyle wrote:
>>>>>> Jaroslav organized the requirements into categories, and the first few
>>>>>> categories are in the agenda for our discussion. PLEASE take a look at
>>>>>> them and be ready to vote. We will try to vote on entire categories
>>>>>> unless there are objections to specific requirements. If you will not be
>>>>>> at the meeting but wish to comment or vote, you may do so in email and
>>>>>> we will do our best to include your views.
>>> -- 
>>> Annette Greiner
>>> NERSC Data and Analytics Services
>>> Lawrence Berkeley National Laboratory
> -- 
> Annette Greiner
> NERSC Data and Analytics Services
> Lawrence Berkeley National Laboratory

Karen Coyle
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Monday, 4 June 2018 19:50:19 UTC