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

Re: Requirements for profiles

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Sat, 18 Nov 2017 13:14:50 -0800
To: public-dxwg-wg@w3.org
Message-ID: <8e6ce100-183e-2bb4-0587-19a3d6e7c180@kcoyle.net>
Rob, I chatted with Phil Archer, who was the author of the charge, and
as I understood him the charge is to define guidance for profiles "in
general" not just DCAT, and that DCAT profiles would try to meet the
terms of that guidance. This is why I am a bit confused about Ruben's
distinction and would like to understand the differences that he perceives.

Here's what I think will be hard to handle in actual application
interactions: let's say that the guidance for APs (or Ps if you wish)
includes the ability, for each property or entity, to define
cardinality, human-readable messages, rules for validating values, etc.
All of these will be *possibilities*, and few will be requirements. In
Ruben's scenario, not only would he need to know which properties are
used in statements about a Person or a Book, but he would probably need
to know what of the optional functions have been defined. That's where
doing "composition" becomes complex. Now, within a certain community,
composition may be possible because you've all agreed on the details of
your profiles. But I don't think it is possible against an arbitrary set
of profiles. What I would like to avoid is having to code profiles based
on their level or type of description of the vocabulary.

I would like to see a real life use case for composition before we take
this further, not a theoretical one. Are there communities that already
take this kind of approach or that have a use case where they need this
kind of approach but are waiting for a way to do it?

kc

On 11/18/17 12:10 PM, Rob Atkinson wrote:
> I dont think there is any inconsistencies between usages of "profile" ,
> "application profile" and "generic profile".  There perhaps seems to be
> a conflation of "application profile" and the specific case of a profile
> of DCAT.
> 
> DCAT is a specification with a broad community scope, and will need
> profiling to be used effectively, as seen.
> 
> Arbitrary separation of requirements will add a lot of extra detail and
> probably a level of inconsistency and confusion. Lets just use DCAT
> profile as a Use Case to make sure DCAT can describe profile usage well.
> 
> Rob
> 
> On 19 Nov 2017 04:34, "Karen Coyle" <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
> 
> 
> 
>     On 11/18/17 4:26 AM, Ruben Verborgh wrote:
>     > Hi Karen,
>     >
>     >> Ruben, I think this is a variant view of profiles, so we should
>     discuss
>     >> it as a group. The APs that exist today for DCAT are complete
>     >> descriptions of all of the elements of a metadata schema.
>     >
>     > Just a reminder that there is a difference
>     > between "profile" in the generic sense,
>     > and "DCAT profile" in the specific sense.
>     >
>     > So there is no contradiction, as I was talking about generic profiles.
> 
>     Therefore we need a good strong definition of "profile" so we can talk
>     about this.
> 
>     We need to know what functions a profile supports, in its most general
>     terms. The Dublin Core profiles may be more specific than this, because
>     their definition includes "application":
> 
>     "The term profile is widely used to refer to a document that describes
>     how standards or specifications are deployed to support the requirements
>     of a particular application, function, community, or context. In the
>     metadata community, the term _application profile_has been applied to
>     describe the tailoring of standards for specific applications." [1]
> 
>     The AP in DCAT-AP is "Application Profile" although there isn't a
>     general definition of what is meant by AP. The document says:
> 
>     "The objective behind DCAT is to facilitate data findability,
>     cross-reference and interoperability between data catalogues on the web
>     by adding a thin layer of agreed upon metadata, to ensure
>     consistency." [2]
> 
>     Our charter also refers to "application profiles" and the
>     deliverable reads:
> 
>     "Guidance on publishing application profiles of vocabularies.
>     A definition of what is meant by an application profile and an
>     explanation of one or more methods for publishing and sharing them." [3]
> 
>     If "profile" is more general than "application profile", we need a
>     definition for that. We may also determine that defining "profile"
>     generically, while possibly useful to the world at large, is out of
>     scope for our work.
> 
>     Could you please create a "straw person" definition for "generic
>     profile" as a starting point? That would help us begin to understand
>     what it means.
> 
>     kc
>     [1] http://dublincore.org/documents/singapore-framework/
>     <http://dublincore.org/documents/singapore-framework/>
>     [2]
>     https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe
>     <https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe>
>     [3] https://www.w3.org/2017/dxwg/charter
>     <https://www.w3.org/2017/dxwg/charter>
> 
>     >
>     > Also, not all profiles have to be "combinable",
>     > so it is fine if DCAT profiles are not.
>     >
>     >> As I read them
>     >> they cannot be combined as they are, nor can parts or fragments be
>     >> combined as new profiles because they haven't been designed to be
>     >> uniformly combinable. That is an interesting interpretation but
>     not one
>     >> that we have yet as a requirement.
>     >
>     > We should, I think. It follows from 5.3.
>     >
>     > Best,
>     >
>     > Ruben
>     >
>     >
> 
>     --
>     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:%2B1-510-984-3600>
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600
Received on Saturday, 18 November 2017 21:15:15 UTC

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