W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > November 2017

RE: Requirements for profiles

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Mon, 20 Nov 2017 16:11:25 +0000
To: Ruben Verborgh <Ruben.Verborgh@UGent.be>, "kcoyle@kcoyle.net" <kcoyle@kcoyle.net>
CC: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <e896e27815e343e8a3ac4b6ff07bcbe3@dnb.de>
On Monday, November 20, 2017 1:21 PM, Ruben Verborgh [mailto:Ruben.Verborgh@UGent.be] wrote:

> > the charge is to define guidance for profiles "in
> > general" not just DCAT, and that DCAT profiles would try to meet the
> > terms of that guidance. This is why I am a bit confused about Ruben's
> > distinction and would like to understand the differences that he perceives.
> I would define them as follows.
> A media type (or content type) defines a set of syntactic constraints, structural
> constraints,
> and/or semantic interpretations that can apply to a given document.
> A profile defines a set of additional structural and constraints and/or semantic
> interpretations
> that can apply to a given document on top of that document's media type.

I have slight issues with "on top of that document's media type". To me profiles are kind of orthogonal to media types. A good example are ODRL profiles [1] that define semantic constraints for data structures. Those data structures can then be expressed in XML [2], JSON [3] or RDF (and the RDF serialised in any RDF serialisation).

We must be careful not to look at profiles/application profiles/generic profiles (to me those are synonyms *in this context*) as something that is only relevant for data in RDF, but as something that constrains data as such regardless of the media type used. I vaguely remember that we decided to differentiate between "profiles" and "schemas" where a "schema" is something we can validate against, e. g. a ShEx document or an XML Schema document.
> A DCAT profile is a profile with structural constraints for datasets.
> (This last definition can be improved; I'm mostly concerned with the first two.)

Yes, perhaps "A DCAT profile is a profile with structural constraints for descriptions of datasets.".

> > Now, within a certain community,
> > composition may be possible because you've all agreed on the details of
> > your profiles. But I don't think it is possible against an arbitrary set
> > of profiles.
> Indeed, and that's not a problem.
> I emphasize that generic profiles can be seen as really simple things.
> Examples of profiles could be:
>  has a "title" element with a string as value
>  has a "links" element with an array as value
> So then, trivially, the following JSON document conforms to both profiles:
> {
>   "title": "My Title",
>   "links": ["http://example.org/"]
> }
> That's how easy things can be.
> > What I would like to avoid is having to code profiles based
> > on their level or type of description of the vocabulary.
> There's no need to do that.
> Note that, even in the trivial example above,
> I'm not mandating that a machine-readable description language exists
> to write those constraints.
> That's not something we want to solve in general.
> > I would like to see a real life use case for composition before we take
> > this further, not a theoretical one.
> Even though I'm the one who brought up the word "composition",
> let's maybe forget about it for now.
> All I was trying to say is that representations can conform to multiple profiles,
> especially if those profiles are lightweight things as in my example above.

The question if this is a real use case is important, though, since it also affects the profile negotiation deliverable: Do we need to have support for negotiation of multiple profiles or not?

[1] https://www.w3.org/TR/odrl-model/#profile
[2] https://www.w3.org/community/odrl/xml/2.1/
[3] https://www.w3.org/community/odrl/json/2.1/


Received on Monday, 20 November 2017 16:11:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:41:58 UTC