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

Re: Requirements for profiles

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Tue, 21 Nov 2017 15:21:32 -0800
To: Rob Atkinson <rob@metalinkage.com.au>
Cc: Antoine Isaac <aisaac@few.vu.nl>, "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>, Valentine Charles <valentine.charles@europeana.eu>
Message-ID: <31343244-c20e-957b-896d-3c9b3085aaf7@kcoyle.net>
Are you referring to value vocabularies? I was thinking about
properties, and in the profiles I've seen they tend to be lists of terms
representing properties and classes.

kc

On 11/21/17 2:18 PM, Rob Atkinson wrote:
> 
> 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
> <mailto: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 <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     m: 1-510-435-8234 (Signal)
>     skype: kcoylenet/+1-510-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
Received on Tuesday, 21 November 2017 23:22:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 25 March 2019 10:33:20 UTC