Re: Requirements for profiles

Profiles should reference controlled vocabularies - and practically these
must be accessible via distributions such as REST API endpoints -
 - consider GBIF biota taxon vocabulary - miilons of terms and changes
every day. Can not embed this in a profile, or even in a static resource.

Rob



On Wed, 22 Nov 2017 at 09:11 Karen Coyle <kcoyle@kcoyle.net> wrote:

>
>
> On 11/21/17 12:25 PM, Antoine Isaac 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
>
> We'll make sure that these get in. I do have a very basic question,
> though, which is whether you have any assumptions about the content of a
> profile. This says that it is documented, that it is machine-readable,
> that it contains validation, and that profiles can contain pieces of
> data from other profiles. Is there some statement that can be made about
> the nature of this data? Are you assuming that profiles contain
> vocabulary terms? This seems to be the missing background information
> from our requirements.
>
> kc
>
> > - 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
> >>>>
> >>>
> >>
> >
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234 (Signal)
> skype: kcoylenet/+1-510-984-3600 <+1%20510-984-3600>
>
>