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.

-Annette

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 Tuesday, 25 June 2019 20:10:57 UTC