W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > November 2017

Re: Requirements for profiles

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Wed, 15 Nov 2017 21:15:12 +0000
Message-ID: <CACfF9LwL-r9Ph-AUvDB3CtJgmj6KPpf7aKOzmFvNRr_w9Qi-BQ@mail.gmail.com>
To: kcoyle@kcoyle.net
Cc: public-dxwg-wg@w3.org
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> 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>> 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> http://kcoyle.net
> >     m: 1-510-435-8234 (Signal)
> >     skype: kcoylenet/+1-510-984-3600 <+1%20510-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 <+1%20510-984-3600>
>
>
Received on Wednesday, 15 November 2017 21:15:56 UTC

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