Re: Profile definition

I think profile negotiation is deeper than the existing support for
serialisation choice already handled by conneg - its about both the content
model and the content choices.

For example a system could deliver a single statement as RDF/XML - or i
could build a graph. For example a DCAT document might have only dcat:
properties of a dataset, or it could include a deep prov-o based history of
changes, and dcat descriptions of the related datasets.
Such a graph would need to be specified as profile - because a client could
never guess what is available and how to specify such a deep traversal in
detail.

I agree "constraints" is funny when we are talking about constraints on
extension points, which in fact introduces a whole new level of detailed
models. Personally am agnostic about terminology, as long as we recognise
this is a first-class concern for both DCAT's descriptive power as well as
the design of DCAT as an information resource in its own right.

(sets of DCAT resources are a dataset - so
profiles/constraints/specifications apply in all cases, but we I think we
can expect DCAT resources to be self-describing using DCAT profile
semantics.. )




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

> Hi Lars, everyone,
>
> On 14/06/17 09:25, Svensson, Lars wrote:
> > Hi Ruben,
> >
> > On Tuesday, June 13, 2017 8:50 PM, Ruben Verborgh [mailto:
> Ruben.Verborgh@UGent.be] wrote:
> >
> >>> We are not talking about DCAP, nor specific profiles of DCAT - we are
> talking about
> >> the _definition of a profile used in DCAP
> >>
> >> Okay; but that wasn't apparent from the mail that started this thread,
> >> which asks for a "working definition of a profile", seemingly in
> general.
> >>
> >> In any case, this brings us to an important point:
> >> we should be very precise when talking about "profile" in this group :-)
> >
> > +1
> >
> >> So is the question what we (as the DXWG group) will consider "a
> profile",
> >> or is this about something more specific?
> >>
> >>> The contents of DCAP itself are not particularly relevant here I think.
> >>
> >> They aren't; I was only talking about profiles in my previous mail, so
> if you wish:
> >>
> >> – DCAP profile ⊂ ProfileNegotiation profile
> >> – ODRL profile ⊂ ProfileNegotiation profile
> >> – DCAP profile ⊄ ODRL profile  and  ODRL profile ⊄ DCAP profile
> >
> > I find the DCAP definition quite good. The only thing I wouldn't use in
> a definition of "profile" is the last bullet point:
> >
> > * defines the machine syntax that will be used to encode the data
> (Syntax Guidelines and Data Formats)
> >
> > The machine syntax should IMHO not be part of the profile but defined in
> one or more schemas (i. e. implementations of the profile), e. g. a SHACL
> document or an XML schema. We then of course need a machine-understandable
> mechanism to link profiles to schemas.
> >
>
> I think I agree to this. And the serializations (in various machine
> syntaxes) would be what is served in profile negotiation. Am I right?
>
> Btw I'm surprised to see that the ProfileNegotiation profile would be more
> general than the DCAP one. DCAP profile is "a document (or set of
> documents) that specifies and describes the metadata used in a particular
> application." This is fairly general. Especially, it includes the
> possibility to specify vocabularies (ontologies) and extensions, which to
> me is more general than 'constraints'. I find the notion of 'constraint'
> becomes quite stretched if we include (in the documents to be served for a
> profile) human-readable documentation, as Karen reminded DCAP does [1].
> But maybe that's because I understand 'constraints' in a more specific
> way, perhaps influences by recent work like SHACL.
> In fact it may be not very far away: ontologies/vocabularies are
> 'specifications' and a broader meaning of 'constraints' could fit this.
> Would there be any strong objection to understanding (and renaming)
> 'constraints' as 'specifications' in the ProfileNegotiation definition? Am
> I misunderstanding anything?
>
> Cheers,
>
> Antoine
>
> [1] https://lists.w3.org/Archives/Public/public-dxwg-wg/2017Jun/0054.html
>
>