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

RE: Requirements for profiles

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Wed, 22 Nov 2017 08:25:47 +0000
To: Antoine Isaac <aisaac@few.vu.nl>, "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <0eb0af5ad67a419dba40707f7ab15864@dnb.de>
Hi Antoine,

On Tuesday, November 21, 2017 9:05 PM, Antoine Isaac [mailto:aisaac@few.vu.nl] wrote:

> Then Karen asked for an example for requirement 5.3. I see the Europeana Data
> Model (or even better, the DPLA metadata application profile [1], which is a built on top
> of EDM) as a such combination, as it re-used several vocabularies at the same time,
> by means of 'combination of combination/constraints' for their elements.
> Well I must say that I'm not 100% sure at which level the notion of profiles sits in this
> combination, i.e. whether it's the end result (the DPLA MAP itself) or the various
> components (i.e. the way EDM 'profiles' DC, plus the way EDM 'profile' SKOS, plus the
> way EDM 'profiles' OAI-ORE, etc).

I'd say that EDM is the (application) profile, since it defines constraints on which elements from which vocabularies are to be used and with what cardinalities. Of course EDM can be seen as a modular profile built on components defined elsewhere, e. g. you could have a profile that defines how to express rights metadata (must have one edm:rights element that must contain a URI pointing to a closed list of pre-defined rights statements and if the rights statement is one that mandates attribution (e. g. CC BY) the rights information also must contain a ex:attributionExample element that shows whom to attribute it to). Then harvesters could search for content that adheres to that profile an know exactly how to extract the relevant information. In a way a bit like how Java interfaces work.

> In any case I'd say that the 5.3 requirement eventually holds, whatever the view of
> profile privileged here (perhaps indeed it should be up to our group to make it
> precise!). To me Ruben's point "conformance to multiple profiles can be indicated (and
> requested)" is the most important: an (application) profile can be said to be a profile of
> several pre-existing building blocks, which could be simply vocabularies, or already built
> profiles.



> On 20/11/17 17:11, Svensson, Lars wrote:
> > 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 Wednesday, 22 November 2017 08:26:13 UTC

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