Re: Profiles vs. extensions

Dear all,
+1 to include guidance on both the cases mentioned by Luiz by saying that
"Application profiles can create an extension to match their needs" as
suggested by Antoine.

I guess Profilers have to  face some with some "extra concerns" when their
profile also extending,
Just to mention some of the possible concerns see BPs in [1].

Cheers,
Riccardo

[1] https://www.w3.org/TR/dwbp/#dataVocabularies


On 19 June 2017 at 17:42, Rob Atkinson <rob@metalinkage.com.au> wrote:

> +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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>


-- 
----------------------------------------------------------------------------
Riccardo Albertoni
Istituto per la Matematica Applicata e Tecnologie Informatiche "Enrico
Magenes"
Consiglio Nazionale delle Ricerche
via de Marini 6 - 16149 GENOVA - ITALIA
tel. +39-010-6475624 - fax +39-010-6475660
e-mail: Riccardo.Albertoni@ge.imati.cnr.it
Skype: callto://riccardoalbertoni/
LinkedIn: http://www.linkedin.com/in/riccardoalbertoni
www: *http://www.imati.cnr.it/ <http://www.imati.cnr.it/>*
http://pers.ge.imati.cnr.it/albertoni/PersonalPage/albertoni.html
FOAF:http://purl.oclc.org/NET/RiccardoAlbertoni/foaf