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

Re: Requirements for profiles

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Wed, 22 Nov 2017 11:07:17 +0100
To: <public-dxwg-wg@w3.org>
Message-ID: <7e5086b5-4c49-5745-b3e5-8cab59bda297@few.vu.nl>
Hi,

Trying to relate to some context - and test whether I've understood it right :-)

I think that what Rob refered to as 'type ontology' corresponds to a kind of 'value vocabulary' that Karen and Makx mentioned.
Btw these 'value vocabularies' were used in the Library Linked Data W3C group, e.g.
https://www.w3.org/2005/Incubator/lld/XGR-lld-20111025/#Appendix_A:_An_inventory_of_existing_library_Linked_Data_resources
there was also 'metadata element sets' mentioned there, which imo correspond to Rob's 'profile properties' - btw as Karen pointed out, this name is tempting, but in a Linked Data context it is confusing as it sets asides RDF Classes, which are an important elements of vocabularies used in profiles.

Antoine

On 22/11/17 09:37, Rob Atkinson wrote:
> dcat:theme  would be the "profiled property"  in this case
> 
> 
> On Wed, 22 Nov 2017 at 18:40 <mail@makxdekkers.com <mailto:mail@makxdekkers.com>> wrote:
> 
>     __ __
> 
>     I am not entirely sure how this fit in the discussion here, but the European DCAT-AP profile does cover value vocabularies. For example, it says that for the values of dcat:theme a conformant implementation MUST use a value from the Publications Office MDR Data theme NAL (http://publications.europa.eu/mdr/authority/data-theme/). ____
> 
>     __ __
> 
>     Would that still be in your definition of a ‘profiled property’ or would this be a different kind of profile?____
> 
>     __ __
> 
>     Makx.____
> 
>     __ __
> 
>     *From:*Rob Atkinson [mailto:rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>]
>     *Sent:* 22 November 2017 04:00
>     *To:* kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>
>     *Cc:* Rob Atkinson <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au>>; Antoine Isaac <aisaac@few.vu.nl <mailto:aisaac@few.vu.nl>>; public-dxwg-wg@w3.org <mailto:public-dxwg-wg@w3.org>; Valentine Charles <valentine.charles@europeana.eu <mailto:valentine.charles@europeana.eu>>
>     *Subject:* Re: Requirements for profiles____
> 
>     __ __
> 
>     +1____
> 
>     __ __
> 
>     __ __
> 
>     On Wed, 22 Nov 2017 at 12:09 Karen Coyle <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> wrote:____
> 
>         OK, so it seems that what I was called "vocabularies" you are calling
>         "profiled properties" and I think yours is the better term. So we are
>         saying that a profile defines a set of properties (and perhaps also
>         classes, in the RDF sense).* I'm not sure what a "type ontology" is,
>         though.
> 
>         Also, a profile may use properties from a number of different
>         ontologies/namespaces, not leaning especially on any one. Sometimes
>         profiles are specializations of a particular ontology or community
>         metadata standard, but sometimes they are bits and pieces that don't
>         lean on any base set. If I combine dct:title and foaf:name and
>         georef:place (I'm making this up) the end result can be a profile. On
>         the other hand the DPLA "modified EDM" is a profile based on EDM,
>         perhaps extended or restricted. These two examples show that profiles
>         can have different relations to one or more base vocabularies.
> 
>         * I once again would like folks to look at the technology stack of the
>         Singapore Framework [1] which may be compatible with the statement that
>         a "profile defines a set of additional structural and constraints and/or
>         semantic interpretations that can apply to a given document on top of
>         that document's media type." If the Framework doesn't have the same
>         sense as the quote, perhaps we can clarify the differences. And
>         eventually I would like to talk about the concept of description sets
>         [2] which is the DCMI view of profiles.
> 
>         kc
>         [1] http://dublincore.org/documents/singapore-framework/
>         And this is a shortcut to the diagram, which may be the most useful
>         part:
>         http://dublincore.org/documents/2008/01/14/singapore-framework/singapore-framework.png
>         [2] http://dublincore.org/documents/dc-dsp/ however some of the details
>         pre-date general acceptance of RDF and need to change, so don't get hung
>         up on how the lower levels of the model are defined
> 
> 
>         On 11/21/17 4:26 PM, Rob Atkinson wrote:
>          >
>          > Profiles should IMHO reference type ontologies where necessary to
>          > further restrict the range of profiled properties (either base
>          > specification or a more general profile).
>          >
>          > e.g. a profile for "spatial area statistics standard X" may require the
>          > statistical dimension property  is related to (has a rdfs:range)  a
>          > 'feature with a polygon geometry' ,
>          >
>          > the "US Census profile" may require this to have a FIPS code and the
>          > 2020 census may require it to be from the set of 2020 US  state
>          > boundaries, by reference to a specific implementation.
>          >
>          > I think "vocabulary" is a set of definitions in the general case, and is
>          > agnostic about how much information model goes along with that set - so
>          > we need to be pretty careful about assumptions as to what it means here.
>          >
>          >
>          >
>          >
>          >
>          >
>          > On Wed, 22 Nov 2017 at 10:21 Karen Coyle <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>
>          > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> wrote:
>          >
>          >     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>
>          >     <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>
>          >     > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> <mailto: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> <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>
>          >     <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> <mailto: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> <tel:+1%20510-984-3600>
>          >     <tel:+1%20510-984-3600>
>          >     >
>          >
>          >     --
>          >     Karen Coyle
>          > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> <mailto: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> <tel:+1%20510-984-3600>
>          >
> 
>         --
>         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>____
> 
Received on Wednesday, 22 November 2017 10:07:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:44:56 UTC