Re: Requirements for profiles

Hi Rob, Karen,

I've gone through Karen's list and compared it to the one Valentine and I had written
https://docs.google.com/spreadsheets/d/1EiOwf99wocAXlYTIXFEsYx_ZYd6S9meVc8xIdVguLdk/
(I can put this in a mail if needed - I was trying to do the comparison fast)
They're actually quite in line, indeed. Maybe we can even say we support more requirements in Karen's list :-)
There's a couple of things that could be discussed/added, though. Feedback welcome!

Cheers,

Antoine

On 21/11/17 21:58, Rob Atkinson wrote:
> 
> 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 <mailto: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
>      >>>
>      >>
>      >
>

Received on Tuesday, 21 November 2017 21:09:00 UTC