Re: Requirements for profiles

NB The links from UC to requirements is not active at the moment - this is
too much work to maintain while the requirements are being moved around,
triaged and renumnber all the time, so the issue is whether the
requirements are met,

This view of profiles is very much what I had taken from the UC (though I'm
not sure about the implications of the final Europeana specific one) - so
hopefully we havent lost it!

Rob



On Wed, 22 Nov 2017 at 07:25 Antoine Isaac <aisaac@few.vu.nl> wrote:

> Hi Karen,
>
> I'm trying to work on it.
> But I have to say I'm a bit lost, what has happened to our use case (5.37)
> and requirements. At some point everything was included at
> https://w3c.github.io/dxwg/ucr/#ID37
> but the requirement list seems to have been really simplified, not the
> only requirement derived from 5.37 is
> https://w3c.github.io/dxwg/ucr/#RID11
>
> When we contributed our use case we had listed these requirements:
> - Each application profile needs to be documented, preferably by
> showing/reusing what is common across profiles
> - Machine-readable specifications of application profiles need to be
> easily publishable, and optimize re-use of existing specification.
> - Application profiles need a rich expression for the the validation of
> metadata
> - publishers (data providers, intermediary aggregators, Europeana and
> DPLA) need to be able to indicate the profile to which a certain piece of
> data (record describing an individual cultural object, or a whole dataset)
> belong.
> - Data publishers need to be able to serve different profiles of the same
> data via the same data publication channel (Web API)
> - Data consumers (intermediary aggregators, Europeana and DPLA, data
> consumers) need to be able to specify the profile they are interested in
> - Europeana needs to be able to accept the data described using EDM
> extensions that are compatible with its EDM-external profile whether it
> doesn't ingest this data entirely (i.e. some elements will be left out are
> they are useless for the main Europeana Collections portal) or it does
> ingest it (e.g. for Thematic Collections portals or domain-specific
> applications that Europeana or third parties would develop)
>
> I'm going to see how it aligns to your list. But I prefered to send you
> our raw list now, so that you can have a brief look at. If just because
> this list supports your point " Also, there are some obvious requirements,
> like being both machine and human-readable, having identifiers, etc., that
> we do not have use cases for". Valentine and I wanted our use case to be a
> motivation for such requirements...
>
> Cheers,
>
> Antoine
>
> On 21/11/17 16:34, Karen Coyle wrote:
> > Because we need to move to FPWD, if we can agree on the requirements for
> > profiles as written here, we can amend those for the next publication of
> > the UCR. We can add a note that these are still in flux.
> >
> > kc
> >
> > On 11/20/17 1:57 PM, Antoine Isaac wrote:
> >> Hi Karen, all,
> >>
> >> Sorry I wanted to do this today but I will probably won't have time,
> >> also seeing that a considerable thread has appeared after your initial
> >> email and will probably require reading...
> >> I'll try to do this week, though reorganization at Europeana is keeping
> >> me busy.
> >>
> >> Very likely regrets for tomorrow by the way :-/
> >>
> >> Antoine
> >>
> >> On 15/11/17 04:32, Karen Coyle 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
> >>>
> >>
> >
>
>