Re: high-level explanation of profile-based content negotiation

Apologies i missed the followup question in this thread.. about how deeply
nested profiles might be...

The answer i think is the order of 10...

For example imagine a citizen science project on invasive weed recording
being done by a school S.. the data profile it would need to specify would
be...

A school S project - being a sub profile of the Education districts data
puboication policy profile..

And also..

A local council invasive weeds dataset
And a state weeds program dataset
And a national biodiversity recording program dataset
And also a GBIF compliant datasource
And also a GEOSS dataset perhaps

And also an OGC observations and measurements compliant data structure
And a "discrete point coverage"


I.e. it is like a interface inheritance in an OO language.. and we should
expect the same sort of depths of hierarchy.

Rob Atkinson

On 26 Jun 2017 1:59 AM, "Antoine Isaac" <aisaac@few.vu.nl> wrote:

> Hi,
>
> I won't have time to come back to the naming/wording discussion on
> contraints in the other thread. But I want to say still here and now that I
> strongly support the idea of applying the mechanism to the sort of
> application profiles we're discussing.
>
> Best,
>
> Antoine
>
> On 19/06/17 19:56, Ruben Verborgh wrote:
>
>> Dear all,
>>
>> Given the other discussions on profiles,
>> it might be good to explain on a high level how
>> Lars, Herbert and myself see the IETF RFC
>> regarding profile negotiation we are editing.
>>
>>
>> SCOPE
>> For the RFC, a profile is a set of structural and/or
>> semantic constraints that can be imposed on a document.
>> It provides extra assumptions/interpretations
>> that a recipient is allowed to make.
>> A document can conform to one or multiple profiles.
>>
>>
>> IDENTIFICATION
>> A profile will be identified by an IRI.
>> This IRI can be dereferenceable,
>> so something meaningful is returned
>> when clients follow that IRI.
>> We do not specify what is returned in general,
>> but can do so for specific cases within this working group.
>>
>>
>> NEGOTIATION
>> On a high level, negotiation works as follows:
>> – A client indicates the profiles it is compatible with
>>    by using their IRIs.
>> – A server aims to return a response
>>    that maximally uses these preferences,
>>    indicating which profiles the response conforms to.
>>
>>
>> As you can see, this mechanism is very generic.
>> This also means it is compatible with any more specific profile,
>> for instance, such as a DCAT application profile
>> (whatever this might become).
>>
>> However, at the same time, we see no reason
>> to tie profile negotiation specifically to DCAT.
>> In fact, tying it to DCAT would reduce
>> the number of applicable use cases
>> and hence the possible uptake.
>>
>> Best,
>>
>> Ruben
>>
>>
>