Re: document biased toward linked data practices

Hi, All,

This will be a huge problem for the group. I am not so sure of giving up of
our work. Even if we focus only in LD we always could say that the document
will be incomplete.

It is not a technical standard recommendation like others in W3C. We must
find a way of writing a document that could help people to publish, in
terms on general recommendations. I do not think that this general
orientation has no usefulness. It is one of the challenges of the group to
find that blend, between the technical and the informal text.

Best Regards,
Laufer

2015-03-15 18:58 GMT-03:00 Makx Dekkers <mail@makxdekkers.com>:

> All,
>
>
>
> I wasn’t able to be on the call so I am not entirely sure in what context
> Yaso made this comment, but I have been thinking along the same lines. It
> seems to me that the current best practices try to take a fairly general
> view, and maybe that is not good.
>
>
>
> If we try to define best practice for any type of data and any type of
> technology, we’ll end up in very general statements like “provide metadata”
> and “provide data in open formats”. How useful is that? How many people in
> the world are going to say: o gosh, I hadn’t thought of that? I’d say
> no-one.
>
>
>
> For example we now say in Best Practice 7: Provide data provenance
> information: Use the Provenance Ontology [PROV-O] to describe data
> provenance. Great, but what people really want to know is, how? And they
> want to see how others are using PROV-O in practice. Or in Best Practice 3:
> Use standard terms to define metadata: Metadata is best provided using RDF
> vocabularies. There is nothing actionable in that advice, which means that
> no-one is going to do anything with it, unless they already know how to do
> that.
>
>
>
> Maybe it would be more useful if we did indeed focus on Linked Open Data –
> in some of the work that I have done, I noted that best practices for LOD
> is something that people are screaming for. Maybe we should limit this work
> to cover advice for publishing tabular data using the DataCube vocabulary
> and how to use DCAT for that kind of datasets, with good examples of
> existing applications and Application Profiles of DataCube and DCAT, with
> additional advice on when and how to use PROV, VOID, VOAF – again with good
> examples from existing implementations to show how it can be done.
>
>
>
> So in summary, I think that the more specific these best practices are,
> the more useful they are going to be. I understand this is completely the
> opposite of what Carlos was arguing, but I don’t think people are going to
> be excited about general advice.
>
>
>
> Makx.
>
>
>
>
>
>
>
>
>
> *De:* yaso@nic.br [mailto:yaso@nic.br]
> *Enviado el:* 13 March 2015 15:30
> *Para:* Public DWBP WG
> *Asunto:* document biased toward linked data practices
>
>
>
> Hi folks,
>
>
> About what I said today at the end of the call:
>
> If we can't think in use cases where Data on the Web is not also Linked
> Data, shouldn't we agree that this Best Practices Document can and need to
> be biased towards Linked Data Best Practices Document?
>
> The BPs doc says at the intro: "The best practices described below have
> been developed to encourage and enable the continued expansion of the Web
> as a medium for the exchange of data."
>
> Imho, it closes the issue raised [1], helps us to decide about open issues
> [2] and make things more clear about the scope of the deliverables - and
> reinforces what phil said today about the "and if you don't want to use it
> then don't complain" :-)
>
> Particularly, I think that we should keep our mind open, even that this is
> to think in situations whether there can be data on the web that is not
> linked data (not trivial, if not impossible?). Somehow this is connected
> with conversations that we left behind, as well as the conversation about
> protocols, for example. Maybe a note of the working group...
>
>
> Salut,
> Yaso
>
> [1] http://www.w3.org/2013/dwbp/track/issues/144
> [2] http://www.w3.org/2013/dwbp/track/issues/open
>



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