Re: Requirements for profiles

"composition" is ill defined in this context.

multiple inheritance - for example Java classes implementing multiple
interfaces, each of which may have a subclass hierarchy, is common, and
useful.

All DCAT needs to do is to allow a dataset to declare conformance with
multiple profiles. The process of "combining" these may be as simple as two
separate validation rules - but note that validation will need to be on a
distribution, so the dataset may conform to profiles of standards, but the
distributions may define the specific implementation profiles, such as
schemas or shapes they implement.

So there is a little bit of semantics required to relate profiles of a
dataset with profiles of a distribution. i.e. the profiles a distribution
conforms to would be the union of the set of profiles declared for the
distribution and the set of profiles delcared for the dataset.

DCAT records themselves may form part of a distribution of a catalog - a
type of Dataset - so the same rules apply - doesnt change anything - DCAT
profiles are merely examples, and how complex they are and how we combine
them is a separate issue around our choice of formalism for the profile. At
the moment we have low level of formalism - multiple profiles expressed as
documents and no way to compare or combine theme.

So if we want to suggest a recommend formalism - which may be for example a
document and one or more SHACL constraints - but also allow for other
formalisms to be used - then the expressiveness and opportunities for
automated combination logic can be improved.

Previously i did some work combining profiles expressed using RDF-Datacube
- and found that a) it was easy enough to combine these, b) sometimes you
just have to flag that two constraints on the same data element exist and
the semantics need to be checked.

for example, if you have a dimension for "sensor type"  that you declare
the Range to be a "TemperatureSensor" and a profile that requires use of a
specific sensor, then you just need to check that this sensor type is
indeed a "TemperatureSensor" - and can add an axiom to declare this if you
wish.

Where we stand now,  without a predictable way to attach profile
descriptions, is a lot of out-of-band documentation that needs to be read
to even identify this is a concern that needs validating.

So in summary, we just need to work out what we need to say for our
existing evidence of a hiearchary of related DCAT application profiles, and
ideally use the W3C canon to define formalisms for these constraints, and
the semantics of combination.

We dont even need to show they can be combined - beyond independent
validation against each profile, however it is probably better to show they
can be easily combined for convenience and to identify at design time
constraints that may possibly conflict.  (BTW I'm happy to provide an
implemention for that combination logic).


Rob

On Sun, 19 Nov 2017 at 08:14 Karen Coyle <kcoyle@kcoyle.net> wrote:

> 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 <+1%20510-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 <+1%20510-984-3600>
>
>