Re: Requirements for profiles

Hi,

First I entirely agree with Lars' comments on the media type. To me this is a different level: the use of vocabularies and profiles is not connected to the use of a media type (say, application/rdf+xml).

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).

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.

Apologies if I'm not making sense: the thread has nearly blown my mind - or perhaps it has ;-)

Antoine

[1] https://dp.la/info/developers/map/

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 Tuesday, 21 November 2017 20:05:16 UTC