Re: Agenda February 6

Plenty of specifications would not have a formalism for that vocabulary in
a form you can reference - for example NetCDF,  UML.   We are, admittedly
most interested in constraints which can be applied to specified elements,
hence there is an implied need for a vocabulary for any specification,
however profiles written as text documents may use all sorts of references
- such as paragraph numbers.

So, IMHO, specifying that a specification can only be a namespace document
for a vocabulary restricts a more general notion of a "data vocabulary".
But we can certainly make strong guidance re a preference for formal
vocabularies as a view of a specification.

What better term than "specification" can we use then?  "formalised
description of a set of implementation constraints" - clunky,

personally happy with the OED definition #1

"An act of identifying something precisely or of stating a precise
requirement. "

https://en.oxforddictionaries.com/definition/specification

The "vauge" - or unspecified - aspects are "exactly what the scope is"
(problematic as discussed above) and "how the specification is stated" -
also something we should not overprescribe.

Is the push back because people are looking for a specific mechanism for
profile DCAT?

There is no reason we can't profile a broader  defintion of profile to
decribe best practices for DCAT profiles :-)

Can the DCAT guidance group not provide a narrower description of profiles
based on the very specific practices they wish to use, and ground this in
the general definition needed to describe the wiser world?

Rob



On Mon, 5 Feb 2018 at 08:38 Antoine Isaac <aisaac@few.vu.nl> wrote:

> Rob, all,
> I guess the gist is still that 'specification' alone at the front sends a
> signal that is vague. Just like the ISO definition - which is indeed not
> inconsistent yet too general.
> But maybe I'm the one missing something here. To me, the base of any
> profile is ultimately (i.e. directly or 'through profiling a profile') a
> data vocabulary. Are there any other cases?
>
> Antoine
>
> On 04/02/18 22:07, Rob Atkinson wrote:
> >
> > Happy to iterate over language - obviously it is not communication well
> enough, because I still don't see why the ISO definition used is
> fundamentally inconsistent with anything discussed. Whilst I maintain that
> an explicit example is required to disprove this, I think the disconnect in
> expectations is sufficient to force a rethink.
> >
> > Looking at the ISO definition:
> >
> > "A set of one or more base standards, and, where applicable, the
> identification of chosen classes, conforming subsets, options and
> parameters of those base standards necessary to accomplish a particular
> function."
> >
> > it seems to be that the logic  "conforming subsets" implies "structural
> constraints and/or semantic interpretations" is not easy enough to follow,
> so lets add explicit trigger words:
> >
> > how about:
> >
> > "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. This definitions allows for the set of constraints may
> be empty, and specifications may be profiles themselves, so that all
> statements about conformance to a specification may be made using the
> single concept of a profile"
> >
> > too wordy perhaps, but has the explicit words we want and spells out the
> logic somewhat redundantly, but more accessibly.
> >
> > Note that the prime focus of this is dcat:Dataset and
> dcat:Distribution,  but making the domain and range explicit doesnt seem to
> add any value, and experience suggests that this is an anti-pattern.
> >
> >
> > Rob
> >
> >
> >
> >
> > On Mon, 5 Feb 2018 at 06:53 <mail@makxdekkers.com <mailto:
> mail@makxdekkers.com>> wrote:
> >
> >     I agree with Ruben here.
> >
> >     The definition as it is now being proposed implies that a namespace
> >     document, i.e. a document that specifies a 'base standard' or
> (better) a
> >     'base vocabulary specification', like http://purl.org/dc/terms/ or
> all
> >     documents under https://www.w3.org/ns/, are 'profiles'.
> >
> >     I would rather see that we stay closer to Ruben's proposal that
> defines
> >     profiles as being fundamentally about "structural constraints and/or
> >     semantic interpretations" related to base vocabulary specifications
> that, in
> >     my opinion, should be declared separately.
> >
> >     In an earlier discussion with Antoine, I argued that namespace
> documents,
> >     i.e. definitions of semantics, and profiles in the sense of Ruben's
> >     definition have different maintenance requirements and that it
> therefore
> >     would make sense to keep them separate. I personally do not see the
> benefit
> >     of lumping these two different types of things together. In
> practice, it has
> >     always been helpful to treat them differently.
> >
> >     Makx.
> >
> >     -----Original Message-----
> >     From: Ruben Verborgh [mailto:Ruben.Verborgh@UGent.be <mailto:
> Ruben.Verborgh@UGent.be>]
> >     Sent: 04 February 2018 19:01
> >     To: kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>
> >     Cc: public-dxwg-wg@w3.org <mailto:public-dxwg-wg@w3.org>
> >     Subject: Re: Agenda February 6
> >
> >      > Ruben, could you take either Rob's or Antoine's suggested
> wordings and
> >      > add what you think would make one of these acceptable to you?
> >
> >     It's unfortunately not that straightforward to just add things to
> the draft
> >     definition.
> >     The definition as a whole takes a different direction than what was
> >     discussed previously.
> >
> >     I think we should start with a list of things we need, and then
> write that
> >     definition, instead of retrofitting another definition.
> >
> >     For instance, something we all seem to agree on is that a profile is
> >     identified by an IRI, that it describes a set of constraints that
> can apply
> >     to a document.
> >     None of these can be found in the current draft.
> >
> >     Best,
> >
> >     Ruben
> >
> >
>
>