Re: Requirements for profiles

Thanks. Could you post it here to the list as a way to highlight it? - kc

On 11/15/17 1:15 PM, Rob Atkinson wrote:
> OK - when I transcribe spreadsheet back into doc today I'll look at ow
> to make this more explicit.
> 
> 
> On Thu, 16 Nov 2017 at 02:48 Karen Coyle <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
> 
>     Great, Rob. Can you make that into one or more requirements? - kc
> 
>     On 11/14/17 8:14 PM, Rob Atkinson wrote:
>     > IMHO 5.3 _is_ about profiles, in that the behaviour of a service as
>     > described requires a number of things from profiles - such as identity
>     > and hierarchy. 
>     >
>     > So, a server listing profiles is a service issue (and scoped to the
>     > negotiation deliverable), but the payload of what is being listed is a
>     > common concern to all three mooted deliverables.
>     >
>     > Rob
>     >
>     > On Wed, 15 Nov 2017 at 14:32 Karen Coyle <kcoyle@kcoyle.net
>     <mailto:kcoyle@kcoyle.net>
>     > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> wrote:
>     >
>     >     All, I'm not sure that this requirement list is complete but
>     it is what
>     >     I could come up with in a short time so that we could have
>     something to
>     >     discuss. [Note to Antoine and Valentine: please see if I correctly
>     >     captured the requirements from your use case.]
>     >
>     >     I want to mention that I believe there may be more than one
>     definition
>     >     of "profile" being used in the use cases. In particular, UC 5.3
>     >     (submitted by Ruben) didn't seem to me to be a function of
>     profiles but
>     >     of the connection service. There may be other such differences
>     in the
>     >     use cases where I'm not sure if the reference is to the
>     profile or to a
>     >     specific selection of instance data.
>     >
>     >     Also, there are some obvious requirements, like being both
>     machine and
>     >     human-readable, having identifiers, etc., that we do not have
>     use cases
>     >     for. I did a talk at the recent Dublin Core conference that
>     included a
>     >     number of requirements of this nature that we may wish to examine.
>     >
>     >     http://dcevents.dublincore.org/IntConf/dc-2017/paper/view/520/643
>     >
>     >
>     >     ****
>     >     profiles list valid vocabulary terms for a metadata usage
>     >     environment (5.37)
>     >
>     >     profile vocabulary lists may be defined as closed (no other
>     terms are
>     >     allowed) or open (other terms are allowed) (5.37)
>     >
>     >     conceptually, profiles can extend other vocabularies or
>     profiles, or can
>     >     be refinements of other vocabularies or profiles (5.37)
>     >
>     >     profiles can be "cascading", inheriting from other profiles or
>     profile
>     >     fragments (discussion at first f2f)
>     >
>     >     profiles reuse vocabulary terms defined elsewhere (Dublin Core
>     profiles;
>     >     no use case)
>     >
>     >     profiles must be able to define finer-grained semantics for
>     vocabulary
>     >     terms that are used (visible in DCAT APs)
>     >
>     >     profiles must be able to express rules that support data
>     validation
>     >     (cardinality, valid values) (5.41)
>     >
>     >     profiles must be able to express cardinality rules of
>     vocabulary terms
>     >     (5.41)
>     >
>     >     profiles can contain links to detailed validation rules or to
>     validation
>     >     applications that can process the profile (5.48)
>     >
>     >     profiles must be able to support information that can drive data
>     >     creation functions, including brief and detailed documentation
>     (5.46)
>     >
>     >     profiles must be able to express what standards (including
>     creation
>     >     rules) the data conforms to (5.43) (5.42)
>     >
>     >     profiles must support discoverability via search engines (5.40)
>     >
>     >     profiles must have identifiers that can be used to link the DCAT
>     >     description to the relevant profile (seems obvious; no use case)
>     >
>     >     *Not covered* (because I didn't know what the requirement
>     would be): 5.3
>     >     Responses can conform to multiple, modular profiles (by Ruben)
>     >
>     >     kc
>     >
>     >     --
>     >     Karen Coyle
>     >     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>
>     <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> http://kcoyle.net
>     >     m: 1-510-435-8234 (Signal)
>     >     skype: kcoylenet/+1-510-984-3600 <tel:+1%20510-984-3600>
>     <tel:+1%20510-984-3600>
>     >
> 
>     --
>     Karen Coyle
>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     m: 1-510-435-8234 (Signal)
>     skype: kcoylenet/+1-510-984-3600 <tel:+1%20510-984-3600>
> 

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

Received on Thursday, 16 November 2017 02:55:23 UTC