Definition of "profile": a counterproposal

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

-- 
Tom Baker <tom@tombaker.org>

Received on Friday, 28 June 2019 08:30:17 UTC