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: luiz.bonino@dtls.nl <mailto:luiz.bonino@dtls.nl>
Mobile: +31 6 24 61 9131
Skype: luizolavobonino
Website: w <>ww.dtls.nl <>
> On 13 Jun 2017, at 04:51, Rob Atkinson <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
> 
>