RE: Profiles vs. extensions

 

The DCAT Application Profile for data portals in Europe does three out of the four bullet points in the DCAT definition of profile:

 

1. Identify mandatory and recommended properties in DCAT
2. Specify properties from other existing vocabularies to be used alongside DCAT
3. Mandate the use of specific controlled vocabularies/URI sets as values for specific properties

 

Makx.

 

From: Luiz Olavo Bonino [mailto:luiz.bonino@dtls.nl] 
Sent: 13 June 2017 09:36
To: public-dxwg-wg@w3.org
Subject: Re: Profiles vs. extensions

 

Hi Rob and all, my 2 cents in this discussion. Yesterday I got confused when I heard everyone talking about application profiles and was not sure whether you were referring to DCAT profiles as defined in DCAT spec: 

 

"A DCAT profile is a specification for data catalogs that adds additional constraints to DCAT. A data catalog that conforms to the profile also conforms to DCAT. Additional constraints in a profile may include:

* A minimum set of required metadata fields 
* Classes and properties for additional metadata fields not covered in DCAT
* Controlled vocabularies or URI sets as acceptable values for properties
* Requirements for specific access mechanisms (RDF syntaxes, protocols) to the catalog's RDF description

“

 

The first time I had contact with DCAT, this was the most interesting feature for our needs. We wanted to be able to define templates (or profiles) for metadata content that needed to be filled by data producers as well as to validate dataset, and its associated metadata, submission to data repositories. Unfortunately, it was never defined in the specs from Jan 2014. Currently we have been experimenting ShEx and SHACL for the validation purpose.

 

We also have been experimenting extending DCAT, specially the Dataset and Distribution classes. In some cases we needed richer provenance information, in other cases we needed relations between datasets and/or distributions and publications, projects or funding programs.

 

In my view, the profiles (as defined in the original DCAT spec) and the extensions serve two clearly distinct purposes. The former allowing for the specification of a given setup of classes (DCAT and extensions), properties and constraints to be followed by whoever provides the metadata content, which also can serve as submission validation. The latter allows for adding properties, classes and relations that were not initially included in DCAT spec. If we can come up with one approach to tackle these two issues, I don’t see any problem in combining them. I just would like that they get solved somehow.

 

Best,

 

 

Luiz Olavo Bonino

CTO FAIR Data

 

Dutch Techcentre for Life Sciences

Visiting address: Catharijnesingel 54 | 3511 GC Utrecht

Postal address: Postbus 19245 | 3501 DE Utrecht

 

E-mail:  <mailto:luiz.bonino@dtls.nl> luiz.bonino@dtls.nl

Mobile: +31 6 24 61 9131

Skype: luizolavobonino
Website: www.dtls.nl <http://www.dtls.nl> 

 

On 13 Jun 2017, at 04:51, Rob Atkinson <rob@metalinkage.com.au <mailto:rob@metalinkage.com.au> > wrote:

 

Hi

 

as part of the profile discussion we are going to run into the distinction between a profile setting rules for how to use a specification, and an extension to a specification.

 

IMHO these may reconciled through extension points:

 

:hereIsAServiceDescription rdfs:range :AbstractServiceDescription

 

myns:MyRESTServiceDescriptionModel rdfs:subClass of  :AbstractServiceDescription

 

 

i.e. a valid subclass providing a concrete model for an object is a restriction on usage of the underlying abstract extension point definition - hence extensions are "application profiles"  

 

but we may also have application profiles that provide rules for concrete properties, and do not introduce new models.

 

Is this a working hypothesis we can live with and avoid too much angst regarding treating support for profiles and extensions as separate Use Cases, but rather flavours of the same one?

 

For the record, I am willing to trial implementation of such a metamodel as part of the modelling the OGC's specification and definition domain - and hopefully be able to convince the membership to accept a Linked Data implementation based on this. (Linked into specref of course Phil!)

 

Rob Atkinson