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
> <http://ckan.org/features-1/metadata/> or schema.org Dataset
> <http://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