Re: Profiles vs. extensions

+1


On Tue, 20 Jun 2017 at 01:06 Antoine Isaac <aisaac@few.vu.nl> wrote:

> Hi,
>
> I agree with Rob's original proposal on including extensions in the scope
> of APs. I think the sentence 'extensions are "application profiles"' could
> be softened though. I would just say that application profiles can create
> extensions to match their needs. An extension is probably not an AP by
> itself, if just since an application uses it together with another (base)
> vocabulary - otherwise it wouldn't be an 'extension' in the first place ;-)
>
> Cheers,
>
> Antoine
>
> On 13/06/17 11:37, Makx Dekkers wrote:
> >
> >
> > 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: luiz.bonino@dtls.nl <mailto: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
> >
> >
> >
> >
> >
> >
> >
>
>