Re: Definition of "profile": a counterproposal

Tom, I like this:

A human- or machine-readable specification that
        clarifies, constrains, combines, excerpts,
        extends, or annotates one or more given data
        specifications.

But would prefer a simpler enumeration like the one from RFC 6906:

"additional semantics (constraints, conventions,
   extensions) that are associated with the resource representation"

So

A human- or machine-readable specification that defines additional
constraints, conventions, or extensions over one or more given data
specifications.

NB: I'm having trouble with the "human or machine-readable" because we
could have both, yet I hate doing "and/or". Plus it's easy to think that
a PDF as "machine-readable". I don't have an answer for this at the moment.

I agree with the second state about "well designed" but I think that
would be appropriate for the guidance document, not DCAT or conneg.

kc

On 6/28/19 1:29 AM, Thomas Baker wrote:
> The "previously adopted" [1] definition of "profile" reads:
> 
>     A named set of constraints 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.
> 
> Peter has very sensibly suggested that we define
> "profile" in a way that ordinary people can understand
> [2] -- and the definition above, in my opinion, fails the
> test of common sense.  I'm sure we can do better.  How
> about, as posted in Github issue #963 [11]:
> 
>     data profile 
> 
>         A human- or machine-readable specification that
>         clarifies, constrains, combines, excerpts,
>         extends, or annotates one or more given data
>         specifications.  
>         
>         A well-designed data profile provides
>         information, useful for describing data in a
>         given context, without semantically contradicting
>         the data specifications on which it is based.
> 
>     data specification
> 
>         A document, or family of related documents,
>         possibly in alternative or complementary human-
>         and machine-readable formats, that provide
>         vocabularies or guidelines usable for describing
>         data.
> 
> Discussion:
> 
> * Follows Antoine's uses of "specification" [3] and "data
>   profile" [7].
> 
> * Takes Andrea's point that "_data_ specifications are the
>   only thing we have been talking about around
>   'profiles'" (emphasis mine). [4]
> 
> * Takes Annette's points: that profiles are about
>   customizing standards and acknowledging reuse; that a
>   profile may be based on multiple standards; and that
>   "an entirely new specification that isn't based
>   substantially on anything previous is not a profile."
>   [5]
> 
> * Draws on the nice definition in RFC 6906, which says
>   that a profile does not alter semantics but only
>   provides additional semantics in the form of
>   constraints, conventions, and extensions. [6]
> 
> * Avoids the reductive and misleading characterization of
>   profiles as "named sets" of anything.
> 
> * Avoids the counter-intuitive notion that extensions are
>   constraints.
> 
> * Provides no basis for the confusing notion that
>   if a profile uses three terms from Dublin Core, it is 
>   "profiling" the DCMI Metadata Terms specification [8].
> 
> * Drops unexplained technical details:
> 
>   * "implementing subclasses of datatypes" (datatypes 
>     are not classes - at least not in RDF [9])
> 
>   * "options and parameters" 
> 
>   * "necessary to accomplish a particular function"
> 
> * Is consistent with the notion of "DCAT profile" (and
>   Dublin Core profiles generally) and with CONNEG (for
>   which it offers a less abstract definition of
>   "specification").
> 
> 
> [1] https://docs.google.com/document/d/10i9oSb548T3EpK0aPFDhBNR8ycy7QFthiJgPx-pdi0Q/edit
> [2] https://www.w3.org/2019/06/25-dxwg-minutes
> [3] https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Jun/0051.html
> [4] https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Jun/0073.html
> [5] https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Jun/0110.html 
> [6] https://tools.ietf.org/html/rfc6906
> [7] https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Jun/0106.html
> [8] https://lists.w3.org/Archives/Public/public-dxwg-comments/2019Feb/0002.html
> [9] https://www.w3.org/TR/rdf11-concepts/#section-Datatypes
> [10] https://w3c.github.io/dxwg/conneg-by-ap/
> [11] https://github.com/w3c/dxwg/issues/963#issuecomment-506650168
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
skype: kcoylenet

Received on Friday, 28 June 2019 18:28:35 UTC