RE: Agenda February 6

Need to be careful that you are not using the term ‘vocabulary’ to mean two slightly different things here.

An ‘RDF vocabulary’ is usually understood as the definition of a set of classes and properties in an RDF namespace, which may also use elements previously defined in other namespaces.

A controlled vocabulary is typically a set of terms with/out definitions. These may have a role as classifiers, which in the RDF world means that they are used as the range of RDF properties. They may be formalized as a SKOS concept scheme or collection.

The term ‘vocabulary’ is often used unqualified so you need to be clear which slant is intended.

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Monday, 5 February, 2018 09:32
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-dxwg-wg@w3.org
Subject: 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<mailto: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> <mailto: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> <mailto:Ruben.Verborgh@UGent.be<mailto:Ruben.Verborgh@UGent.be>>]
>     Sent: 04 February 2018 19:01
>     To: kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net>>
>     Cc: public-dxwg-wg@w3.org<mailto:public-dxwg-wg@w3.org> <mailto: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
>
>