RE: Trying to articulate our various "profiles"

I tend to agree. 

'Specification' is the general case. 

While all specifications have dependencies, 'Profiles' are the subset where an explicit dependency(s) is(are) somehow essential to their use. 

The patterns are clear, and the same model (e.g. the Profiles vocabulary) could likely be used to describe all cases. But use of the term 'Profile' for the general case appears to be confusing to the market. 


-----Original Message-----
From: Annette Greiner [] 
Sent: Wednesday, 26 June, 2019 06:11
Subject: Re: Trying to articulate our various "profiles"

Please accept my regrets. I'm going to have to miss today's meeting, but I wanted to weigh in on this discussion.

As I see it, the real problem we have is that we have sometimes considered profiles to include specifications like DCAT and sometimes not. That difference suggest to me that we haven't got a consistent term and are therefore developing inconsistent recommendations. It means we need to rethink our definitions.

We could remedy the issue by enlarging all definitions of profiles to include specifications, or by defining profiles more narrowly and referring to the entities that can be negotiated or "conformedTo" with a term that applies to both profiles and specifications. ("metamodel
negotiation"?) I find attempts to do the former odd and forced.

I'm uncomfortable defining profiles such that they include formal specifications. I think that breaks with existing understanding in a way that is confusing. I understand that a specification can be seen as a profile of itself, sort of the trivial case of a profile that is based on the standard without adding any constraints. But the whole purpose of using profiles has always been to codify a customized version of a formal standard. I like the idea of allowing profiles that are based on multiple standards, and I agree that there needn't be a single base standard, but I think an entirely new specification that isn't based substantially on anything previous is not a profile. If it is, then all specifications are profiles, and we've defined nothing new.

Profiling is about acknowledging a reuse. The threshold at which that acknowledgment is called for would be hard to define, but it seems to me that it is up to the creator of the spec or profile what level of acknowledgment they want to advertise. For example, I don't think that DCAT becomes a profile of vCard by including vCard elements. And I don't think we would want to advertise it as such, because we don't have the goal of creating a version of vCard that suits the needs of a specific community. I think it comes down to the intent.


On 6/25/19 10:43 AM, Karen Coyle wrote:
> Antoine, this is excellent and thank you for this analysis.
> So the full definition would be:
> "A named set of constraints which can be based on one or more 
> identified base specifications, including the identification of any 
> implementing subclasses of datatypes, semantic interpretations, 
> vocabularies, options and parameters of those base specifications 
> necessary to accomplish a particular function."
> I wouldn't mind reducing the list of possible elements there, if we can.
> It's kind of a mouthful. Perhaps we can revisit those when we've gone 
> a bit further into the discussion.
> kc
> On 6/25/19 9:43 AM, Antoine Isaac wrote:
>> "A named set of constraints, which can be based on one or more other 
>> identified specifications, [etc]"

Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory

Received on Wednesday, 26 June 2019 03:31:48 UTC