RE: Requirements for profiles

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/

Best,

Lars

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