What is normative?

Hi all,

I think that when we have technical recommendations (as HTML5, CSVW, etc.),
these words are important because people build tools that expect that
something that claims using one specific recommendation would be formatted
(or behave) in a standard way.

I think that our BP document assess, in some sense, the quality of
something that is published. Not the quality of the Dataset, but the
quality of the publishing. So, it makes sense to have a kind of scale (as
ODI is doing with certificates).

I agree with Joao that it introduces a kind of multi-level conformance
schema.

But I think that it is softer than using the RFC words.

So I agree with Bernadette in removing the RFC words and working in a kind
of mature model of publication.

Best Regards,
Laufer

Em segunda-feira, 18 de maio de 2015, Bernadette Farias Lóscio <
bfl@cin.ufpe.br> escreveu:

> Dear all,
>
> I'd like to propose the removal of the RFC keywords from the DWBP
> document.
>
> Cheers,
> Bernadette
>
> 2015-05-18 18:17 GMT-03:00 Bernadette Farias Lóscio <bfl@cin.ufpe.br>:
>
>> +1 Annette!
>>
>> 2015-05-18 18:07 GMT-03:00 Annette Greiner <amgreiner@lbl.gov>:
>>
>> Take a look at how WCAG does it [1]. They don’t use RFC2119 keywords.
>>> Instead, they add “(Level A)”, “(Level AA)”, etc.  Where terms like “must”
>>> and “should” arise in the text, they are treated as they are used in plain
>>> English. That obviates the awkwardness of trying to make keywords that were
>>> developed for specifying a technology work for best practices documents. In
>>> my view, using RFC2119 keywords makes our documents appear to be imposing
>>> actual requirements, which I think is potentially confusing for readers. It
>>> suggests that failure to follow a given BP will prevent users from being
>>> able to access the data. The nice thing about going without the keywords is
>>> that it means people can claim a lower level of conformance and still feel
>>> good, whereas people who meet the higher standard can claim that and feel
>>> even better. We wouldn't need to compromise on what we expect from people,
>>> and we could provide some stretch goals.
>>>
>>> One particular section of that RFC particularly bothers me in
>>> considering its use for best practices. It’s the following:
>>>
>>> 6. Guidance in the use of these Imperatives
>>>
>>>    Imperatives of the type defined in this memo must be used with care
>>>    and sparingly.  In particular, they MUST only be used where it is
>>>    actually required for interoperation or to limit behavior which has
>>>    potential for causing harm (e.g., limiting retransmisssions)  For
>>>    example, they must not be used to try to impose a particular method
>>>    on implementors where the method is not required for
>>>    interoperability. [2]
>>>
>>> [1] http://www.w3.org/TR/WCAG20/
>>> [2] https://www.ietf.org/rfc/rfc2119.txt
>>>
>>> --
>>> Annette Greiner
>>> NERSC Data and Analytics Services
>>> Lawrence Berkeley National Laboratory
>>> 510-495-2935
>>>
>>> On May 18, 2015, at 12:09 PM, Joao Paulo Almeida <jpalmeida@ieee.org>
>>> wrote:
>>>
>>> Hi Annette,
>>>
>>> That just changes the use of the normative statements a bit.
>>>
>>> I proposed to interpret the normative statements in the following way:
>>> if you claim conformance, you MUST, ...
>>>
>>> What you are proposing sounds like: if you claim conformance to level X,
>>> you MUST, ...
>>>
>>> regards,
>>> João Paulo
>>>
>>>
>>>
>>> On Mon, May 18, 2015 at 3:32 PM, Annette Greiner <amgreiner@lbl.gov>
>>> wrote:
>>>
>>>> We’ve had an idea at various times to assign a rating system, something
>>>> like the five stars but different enough to avoid confusion. I still think
>>>> that’s the best way to deal with this issue. It enables a publisher of data
>>>> to claim a concrete level of compliance, much like the WCAG.
>>>> -Annette
>>>> --
>>>> Annette Greiner
>>>> NERSC Data and Analytics Services
>>>> Lawrence Berkeley National Laboratory
>>>> 510-495-2935
>>>>
>>>> On May 18, 2015, at 8:17 AM, Phil Archer <phila@w3.org> wrote:
>>>>
>>>> > The issue is open in tracker so I'm taking it as open - but if we're
>>>> taking them out (and I think we are too) then some of the intro matter and
>>>> the template need updating.
>>>> >
>>>> > Phil
>>>> >
>>>> > On 18/05/2015 16:03, yaso@nic.br wrote:
>>>> >> I thought we had an agreement on this:
>>>> >>
>>>> >> "An alternative would be not to include any RFC2119 keywords at all"
>>>> >>
>>>> >> I ran trough the logs and couldn't find nothing against not using the
>>>> >> RFC2119 keywords at the document. Furthermore, we talked at the F2F
>>>> >> about the translation to Portuguese problem with the keywords. There
>>>> was
>>>> >> another decision on that?
>>>> >>
>>>> >>
>>>> >> yaso
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On 05/18/2015 11:53 AM, Phil Archer wrote:
>>>> >>> Dear all,
>>>> >>>
>>>> >>> The BP editors have been working hard and have made a number of
>>>> what I
>>>> >>> think are big steps forward with the doc.
>>>> >>>
>>>> >>> But Issue-146 remains unresolved: what is normative in a BP?
>>>> >>>
>>>> >>> Take our old favourite first BP
>>>> >>> http://w3c.github.io/dwbp/bp.html#ProvideMetadata that says:
>>>> >>>
>>>> >>> Metadata MUST be provided for both human users and computer
>>>> applications
>>>> >>>
>>>> >>> I doubt anyone here will disagree with this statement, but is it
>>>> right
>>>> >>> to make this the normative part of the BP? And, if so, are we right
>>>> to
>>>> >>> use the RFC2119 MUST?
>>>> >>>
>>>> >>> Take a less clear cut example:
>>>> >>> http://w3c.github.io/dwbp/bp.html#MultipleFormats that says:
>>>> >>>
>>>> >>> Data SHOULD be available in multiple data formats.
>>>> >>>
>>>> >>> Really?
>>>> >>>
>>>> >>> SHOULD is "comply or explain" - i.e. you'd better have a very good
>>>> >>> reason not to provide data in multiple formats so I might argue one
>>>> day
>>>> >>> that this should be a MAY. What does MAY mean? From the infamous
>>>> RFC2119:
>>>> >>>
>>>> >>> "This word, or the adjective "OPTIONAL", mean that an item is
>>>> >>>    truly optional.  One vendor may choose to include the item
>>>> because a
>>>> >>>    particular marketplace requires it or because the vendor feels
>>>> that
>>>> >>>    it enhances the product while another vendor may omit the same
>>>> item."
>>>> >>>
>>>> >>> (I've omitted the rest of the definition but this is the essence of
>>>> it).
>>>> >>>
>>>> >>> Suppose the WG agrees and this BP now becomes:
>>>> >>>
>>>> >>> "Data MAY be available in multiple data formats."
>>>> >>>
>>>> >>> Which doesn't really convey in a single sentence what we mean. We
>>>> might
>>>> >>> end up with
>>>> >>>
>>>> >>> "Publishers are encouraged to make data available in multiple
>>>> formats
>>>> >>> (OPTIONAL)"
>>>> >>>
>>>> >>> i.e. re-word the normative line to fit in with the definition of the
>>>> >>> relevant RFC2119 keyword.
>>>> >>>
>>>> >>> An alternative would be not to include any RFC2119 keywords at all.
>>>> I'm
>>>> >>> easy either way - I can see arguments for and against including
>>>> these
>>>> >>> keywords - but it remains an open issue that I think we owe it to
>>>> the
>>>> >>> editors to decide what to do.
>>>> >>>
>>>> >>> Phil.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>> > --
>>>> >
>>>> >
>>>> > Phil Archer
>>>> > W3C Data Activity Lead
>>>> > http://www.w3.org/2013/data/
>>>> >
>>>> > http://philarcher.org
>>>> > +44 (0)7887 767755
>>>> > @philarcher1
>>>> >
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Bernadette Farias Lóscio
>> Centro de Informática
>> Universidade Federal de Pernambuco - UFPE, Brazil
>>
>> ----------------------------------------------------------------------------
>>
>
>
>
> --
> Bernadette Farias Lóscio
> Centro de Informática
> Universidade Federal de Pernambuco - UFPE, Brazil
>
> ----------------------------------------------------------------------------
>


-- 
.  .  .  .. .  .
.        .   . ..
.     ..       .