Re: Profile definition

I dont think these definitions are mutually inconsistent, but the DC one is
perhaps the most general as it applies to more aspects.

We have profiles in two places of course:

1) profiles of DCAT
2) DCAT description of what profiles of other specifications a dataset or
its access methods conform to.

Being consistent allows DCAT to describe collections of DCAT instances :-)
 And makes our life easier avoiding multiple definitions of terms in
different contexts.

Rob


On Tue, 13 Jun 2017 at 22:15 Svensson, Lars <L.Svensson@dnb.de> wrote:

> All,
>
>
>
> I don’t have a formally settled definition of profile but just want to
> point to two more definitions:
>
>
>
> 1)    In ODRL a profile is something that offers a community a way to
> specify “a more focussed and specific set of terms that meets their
> sector's requirements more precisely” and goes on to say that “an ODRL
> Profile directly and explicitly serves their communities needs by
> specifying only the terms they wish to support in ODRL expressions.” [1] I
> think this one is very interesting since ODRL can be expressed using
> several different media types (e. g. XML, JSON-LD and RDF/OWL) [2] and the
> profiles apply no matter which media type I use to encode my data.
>
> 2)    In the context of profile negotiation, Ruben, Herbert and I agreed
> on the definition of profile as “a set of structural and semantic
> constraints of representations, which can apply in addition to syntactic,
> structural, and semantic constraints defined by a MIME type.” [3]
>
>
>
> [1] https://w3c.github.io/poe/model/#profile-motivation
>
> [2] https://www.w3.org/TR/odrl-vocab/#encodings
>
> [3]
> https://github.com/ProfileNegotiation/I-D-Accept--Schema/issues/11#issuecomment-296628638
>
>
>
> Best,
>
>
>
> Lars
>
>
>
> *** Lesen. Hören. Wissen. Deutsche Nationalbibliothek ***
>
> --
>
> Dr. Lars G. Svensson
>
> Deutsche Nationalbibliothek
>
> Informationsinfrastruktur
>
> Adickesallee 1
>
> 60322 Frankfurt am Main
>
> Telefon: +49 69 1525-1752 <+49%2069%2015251752>
>
> Telefax: +49 69 1525-1799 <+49%2069%2015251799>
>
> mailto:l.svensson@dnb.de
>
> http://www.dnb.de
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Tuesday, June 13, 2017 5:14 AM
> *To:* Simon.Cox@csiro.au; rob@metalinkage.com.au; public-dxwg-wg@w3.org
> *Subject:* Re: Profile definition
>
>
>
> Thanks Simon,
>
>
>
> I was _aware_ of it - but its not yet clear to me whether the scope of
> application profiles discussed there fully covers the requirements under
> discussion here.
>
>
>
> It would be great if Andrea or someone could provide a pointer to a formal
> definition as settled on within this community (so far in discussions this
> has not been offered as a straw man, and only the question "what is a
> profile" has been raised.)
>
>
>
> Rob
>
>
>
>
>
> On Tue, 13 Jun 2017 at 12:47 <Simon.Cox@csiro.au> wrote:
>
> Assume you are already aware of
> https://joinup.ec.europa.eu/asset/dcat_application_profile/home
>
> which I think is where the whole idea of DCAT profiles was most
> comprehensively discussed until now.
>
>
>
> Simon
>
>
>
> *From:* Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Tuesday, 13 June, 2017 12:35
> *To:* public-dxwg-wg@w3.org
> *Subject:* Profile definition
>
>
>
> Looking for a working definition of a profile - here's a starter from
> Dublin Core [1]
>
>
>
> "A DCAP is a document (or set of documents) that specifies and describes
> the metadata used in a particular application. To accomplish this, a
> profile:
>
>    - describes what a community wants to accomplish with its application
>    (Functional Requirements);
>    - characterizes the types of things described by the metadata and
>    their relationships (Domain Model);
>    - enumerates the metadata terms to be used and the rules for their use
>    (Description Set Profile and Usage Guidelines); and
>    - defines the machine syntax that will be used to encode the data
>    (Syntax Guidelines and Data Formats)."
>
>
>
> I think service access is possibly another dimension of profile - and in
> fact I'd like to model profiles as n-dimensional, with the ability to label
> (soft-type) each of the dimensions an AP chooses to qualify.
>
>
>
> So, even though we are not going to define any specific AP, I think we
> need to decide if we will define a meta-model for an AP, in terms of
> attachment points for each of these aspects, as well as self-reporting
> identification of the set of APs a document conforms to.
>
>
>
> Any advances on this definition  before I have a go at defining generic
> Use Case(s) that covers this scope?
>
>
>
> [1] http://dublincore.org/documents/profile-guidelines/#sect-2
>
>