Provide a safe home for definition of "data profile"

[rob-metalinkage]

Profiles include "functional" profiles, such as examples for OGC services (a prime motivating use case for design and implementation of profiles) - and the Conneg document needed to distinguish between profiles of the specfication itself and the data profiles that are being negotiated.

Proposal:
Add a subclass of Profile called DataProfile which carries the "data profile" definition agreed and does not restrict the usefulness of the general model.

Pros:

1. makes it clear that profiles may be data profiles
2. makes it clear that other types of profiles may exist
3. makes it possible to distinguish that a particular profile is specifically about requirements for data content rather than functional behaviours.

Cons:

1. (now redundant ) not originally modelled because "data profile" wasnt originally an identifiable thing with an agreed definition
2. begs the question whether other sub-types should be modelled
3. redundant if systems declare what the profile is about in other ways

Those "cons" I think can now be dismissed - we dont have time or motivations to agree definitions for other sub-types and absence doesnt impact utility of what is modelled, and we dont have canonical ways to describe the scope of a dct:Standard available, so this subClass has semantic value.

[kcoyle]

The bigger "con" is that you are 5 days from the drop-dead date for getting a final version to the working group, and so adding new concepts seems quite dangerous. This could be placed on a "later version" path.

[rob-metalinkage]

Happy to leave definition of "data profile" as a future work item - and consider a richer typology of profiles then. What we cannot do now is to introduce the definition of "data profile" in any normative way as it doesnt match the scope - what we can do is add it within a usage note saying its an example...

[aisaac]

I've argued against calling "functional profiles" in Conneg with word "profile". I've not fought for it a lot, but I think my points then still apply: there can be a case for having a generalized model for profiles. But still the main object of Conneg is negotiating for data profiles, and putting other notions in the doc has a negative impact on the clarity on the main goal. Maybe we can get along with it in Conneg but it shouldn't distract us and the readers of our specs from the main focus, which is clear in the use cases and requirements, and as a matter of fact in our charter: https://www.w3.org/2017/dxwg/charter#goals

So I believe this issue is turning things upside down. As a WG, our mandate is to start from data profiles. And we may work on providing a home for a generalized definition on top of that. Not the other way round.

[larsgsvensson]

@aisaac So what exactly do you suggest that we do?

[aisaac]

@larsgsvensson we keep to "data profiles" and not seek to generalize any further for now.

[kcoyle]

I think this can be closed as "out of scope"