Re: Comments on Best Practice document

Hi,

I agree with Makx that "in several cases, the why section explains why
a best practice is needed, not why this particular practice is “best”
practice."

The initial motivation for the Why section was guided by two main
questions that helped us to identify if a BP is in the scope of DWBP
or not:

1. Why this is unique to publishing or reusing data on the Web?
2. How does this encourages publication or reuse of data on the Web?

I think the second question may help to answer your question. However,
we can also add one or more questions in the Why section (or to
include another section) that will help to explain "why this
particular practice is “best” practice."" However, I'm not sure if
this is gonna be enough.

Another way of showing that BPX is really a BP is making experiments.
Some real cases can be used to show that BPX helped to improve the
interaction between publishers and consumers, for example. In this
case, we will need specific criteria to evaluate the BP and also some
metrics.

Cheers,
Bernadette



2015-01-23 6:25 GMT-03:00 Makx Dekkers <mail@makxdekkers.com>:
> OK, we agree.
>
>
>
> In addition to the title there is also the subtitle or by-line or what you
> want to call it. That by-line is in most cases more descriptive than the
> title.
>
>
>
> My point was just that some of the Why sections do not make a strong case
> for the specific best practice proposed, and leave room for questions. Maybe
> we need to go through a phase of formulating critical questions on those
> sections (the “yes, but” type) to strengthen them.
>
>
>
> Makx.
>
>
>
>
>
>
>
>
>
> From: Carlos Iglesias [mailto:carlos.iglesias.moro@gmail.com]
> Sent: Friday, January 23, 2015 10:16 AM
>
>
> To: Makx Dekkers
> Cc: Public DWBP WG
> Subject: Re: Comments on Best Practice document
>
>
>
> Good, I think we may talking about the same then, sorry if I misunderstood
> you before:
>
>
>
> - The BP is indicated by the title and should be further explained in the
> why section (why this is a best practices, what's the expected benefit...)
>
> - The full BP (and other document sections) must be technologically neutral
> (even for those where there may be just one implementation option
> currently), with the exceptions of the possible approach implementation
> section.
>
> - Diverse alternative techniques are expected for the possible approach
> section (e.g. using DCAT OR schema.org OR the CKAN data model). None of them
> is better than other and all them are possible valid alternatives to fulfill
> the best practice. The final decision on what technique to use is up to the
> publishers accordingly to their what better fit their needs.
>
> - BPs should be valuable and inclusive for a diverse audience with as much
> alternative techniques as possible. For an exclusively Linked Data audience
> we already have the Best Practices for publishing Linked Data document.
>
>
>
> Do we agree on this?
>
>
>
> Best,
>
>  CI.
>
>
>
> On 23 January 2015 at 08:54, Makx Dekkers <mail@makxdekkers.com> wrote:
>
> Carlos,
>
>
>
> I wasn’t forgetting anything, I was just saying that in several cases, the
> why section explains why a best practice is needed, not why this particular
> practice is “best” practice.
>
>
>
> And yes, I understand that the possible approaches are just possible
> alternatives but we have to be careful not to focus too much on only one
> type of environment (five star linked data) and forget about the rest. The
> example I gave is the “possible approach” in BP3 which does not leave room
> for discussion: use RDF vocabularies for metadata. Period. My question was:
> are these best practices for use in Linked Data publication projects or are
> they supposed to be read by a more diverse audience? If we write these for
> Linked Data people, it’s fine with me. If not, we may need to be a little
> more inclusive.
>
>
>
> Makx.
>
>
>
>
>
>
>
> From: Carlos Iglesias [mailto:carlos.iglesias.moro@gmail.com]
> Sent: Thursday, January 22, 2015 11:25 PM
> To: Makx Dekkers
> Cc: Public DWBP WG
> Subject: Re: Comments on Best Practice document
>
>
>
> Hi Makx,
>
>
>
> Very interesting reasoning, but I think that you may be forgetting that the
> real Best Practice is just what we have in the BP title in combination with
> the expected outcome. The possible implementations are just that, possible
> alternatives for implementation.
>
>
>
> As alternatives there is no one implicitly better than other beforehand, as
> the best alternative is likely to depend of the specific use case and
> environment (domain, technological stack, etc.) That's something unknown for
> us and thus the final user decision.
>
>
>
> Think again about the analogy with WCAG2 where the guidelines are
> independent and neutral and then they have specific techniques for different
> technologies to fulfill the guidelines requirements. Here we are trying to
> do the same (at least that's my understanding) with the only difference that
> we are putting all techniques together at the implementation section instead
> having one implementation section (or document) per technology.
>
>
>
> Best,
>
>  CI.
>
>
>
>
>
>
>
> On 22 January 2015 at 19:17, Makx Dekkers <mail@makxdekkers.com> wrote:
>
> All,
>
>
>
> First of all, apologies that I haven’t been able to give proper attention to
> this work over the past couple of weeks due to heavy workload and family
> matters.
>
>
>
> I now have had a chance to read through the current version and I’d like to
> congratulate the people who worked so hard on it. It is coming together
> quite nicely!
>
>
>
> However, I do have some comments. Not things that are show-stoppers but
> maybe things we can talk about for next versions.
>
>
>
> My general point is a question that has been lingering in my mind for a
> while now. The question is: how do we determine what is “best” practice?
> Reading the document, I can sort of understand why the things mentioned in
> the titles and summary statements of the BPs are reasonable things to do,
> but for things to be declared “best” practice, I would maybe expect a brief
> analysis of the options and relative merits of possible alternatives.
> Currently, the best practices described are what some of us, or all of us in
> this small group, think is the best way to meet a requirement. But is that
> sufficient justification?
>
>
>
> An example is Best Practice 1: Provide metadata that says that Data on the
> Web MUST be described by metadata.  The “Why” section makes a general
> statement that without metadata, you can’t find anything. A reader might
> ask: “What about Google? They’ve been working fine without metadata!” Some
> people might create a landing page for their dataset and do some smart SEO
> on it. What would our response be?
>
> Further down it says that DCAT should be used to describe datasets as a
> whole. Now someone might ask: “So is publishing CKAN metadata format or
> schema.org Dataset somehow worse practice?” To be clear, I do strongly agree
> that people should provide metadata and I do agree that DCAT has certain
> advantages, but shouldn’t the BP say why the proposed approach is better
> than others?
>
>
>
> Reading on, I could come up with similar questions for many of the other
> Best Practices. In many cases, the “Why” section explains more why we think
> you need a best practice for a particular aspect, but it does not always
> clearly justify the specific best practice proposed. Possible approaches
> sometimes contain statements that we might consider self-evident, universal
> truths, e.g. “Metadata is best provided using RDF vocabularies”. Some people
> might agree, some might not. In this case, someone who works in a JSON or
> XML environment might not agree for practical reasons, and happily ignore
> the best practice. Is that what we want?
>
>
>
> I don’t want to delay this version but maybe we can have some of these
> issues on the agenda of the group for further discussion.
>
>
>
> Makx.
>
>
>
>
>
>
>
>
>
> --
>
> ---
>
>
>
> Carlos Iglesias.
>
> Internet & Web Consultant.
>
> +34 687 917 759
>
> contact@carlosiglesias.es
>
> @carlosiglesias
>
> http://es.linkedin.com/in/carlosiglesiasmoro/en
>
>
>
>
>
> --
>
> ---
>
>
>
> Carlos Iglesias.
>
> Internet & Web Consultant.
>
> +34 687 917 759
>
> contact@carlosiglesias.es
>
> @carlosiglesias
>
> http://es.linkedin.com/in/carlosiglesiasmoro/en



-- 
Bernadette Farias Lóscio
Centro de Informática
Universidade Federal de Pernambuco - UFPE, Brazil
----------------------------------------------------------------------------

Received on Friday, 23 January 2015 13:15:42 UTC