- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Wed, 15 Nov 2017 21:15:12 +0000
- To: kcoyle@kcoyle.net
- Cc: public-dxwg-wg@w3.org
- Message-ID: <CACfF9LwL-r9Ph-AUvDB3CtJgmj6KPpf7aKOzmFvNRr_w9Qi-BQ@mail.gmail.com>
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