Re: DCAP - some background

Great input. Thanks Karen!


Its important we separate profiles _of_ DCAT and support for describing
profiles of dataset specifications a dataset may conform to.

Supporting multiple expressions of a given profile in DCAT may help users
get familiar with the usage and discovery of profiles of DCAT. Certainly
the uptake issue needs thought.

Rob Atkinson





On 15 Jun 2017 3:14 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

Here's some background on the Dublin Core application profiles work.
(Sorry for the length; and I really tried to keep it short!)

First, it's important to see the historical context behind DCAP. Dublin
Core was working in parallel to the W3C work on RDF during the 2000's.
In particular, DC developed an Abstract Model, DCAM,[1] to anchor its
work. I was not involved in DCAM but I read it today as a set of design
patterns for the definition of ones' metadata. It is mainly compatible
with RDF, and is the anchor component in a broad metadata framework.[2]

The metadata framework itself included a number of components, which are
defined in the Singapore Framework for Application Profiles[2]. The
framework is a holistic approach to metadata vocabularies and
documentation, including domain models, general vocabularies,
application profiles, and guidance (aka cataloging rules). In this
model, base vocabularies would be minimally semantically constrained so
that they could be given sharper definitions (such as domains and ranges
and value rules) in the application profile.

Before I go on to the application profiles, let me say that the DC
abstract model did NOT get uptake in the community (meaning the large
community that uses DC for various functions). It may have been ahead of
its time, but I personally found its terminology ("non-literal value
surrogate" etc.) to be daunting. Perhaps a primer would have made a
difference. This lack of uptake of the DCAM possibly was the big
hindrance to the acceptance of the Dublin Core Application Profiles
(DCAP), which was based on the DCAM. Note that the document that I
co-authored with Tom Baker was an attempt to provide a primer-like
approach to the DCAP concept.

Because Dublin Core is at its core (sorry) an instance data vocabulary,
the DCAP is illustrated as a definition of a profile for instance
metadata. It could also presumably be applied to the description of a
dataset, but that has not been a focus in Dublin Core work.

What is key to the DC approach is evidenced in what I see as the pattern
of "description sets". The abstract model provides design patterns for
descriptions that are united into description sets. Each of those
descriptions consists of statements about some thing. The Description
Set Profiles[3] document defines a constraint language for description
sets. The "application profile" is a broader concept that includes
additional documentation such as domain models and base vocabularies. So
strictly speaking the DCAP > DCAT-AP, and a better equivalence would be
DSP~=DCAT-AP. (But I see no reason not to use DCAP in the narrower sense
for our discussions.)

In my brief reading of DCAT-APs, the DSP appears to be a slightly more
robust AP definition, with a more complete model for the definition of a
vocabulary profile (cardinality, validity rules for values, etc.).
However, having sat on the SHACL-WG for over 2 years, what I also now
see as missing are the possible relationships between descriptions and
between statements (A or (B and C)). This leads me to think that the
picture is (unfortunately) even more complex when we consider the
delineation between vocabulary definition and validation. The hope was
that the DSP could directly translate to machine validation, but I'm now
wondering if instead we need a hook between the vocabulary profile and
the documentation/validation aspects.

kc
[1] http://dublincore.org/documents/abstract-model/
[2] http://dublincore.org/documents/singapore-framework/
[3] http://dublincore.org/documents/dc-dsp/
--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600