RE: Comments on Best Practice document

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 <http://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 <mailto: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 <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 <mailto: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 <tel:%2B34%20687%20917%20759>  

 <mailto:contact@carlosiglesias.es> contact@carlosiglesias.es 

@carlosiglesias 

 <http://es.linkedin.com/in/carlosiglesiasmoro/en> http://es.linkedin.com/in/carlosiglesiasmoro/en





 

-- 

---

 

Carlos Iglesias. 

Internet & Web Consultant.

+34 687 917 759 

 <mailto:contact@carlosiglesias.es> contact@carlosiglesias.es 

@carlosiglesias 

 <http://es.linkedin.com/in/carlosiglesiasmoro/en> http://es.linkedin.com/in/carlosiglesiasmoro/en