W3C home > Mailing lists > Public > public-dwbp-comments@w3.org > July 2015

Re: some comments on the DWBP draft

From: Bernadette Farias Lóscio <bfl@cin.ufpe.br>
Date: Thu, 30 Jul 2015 13:07:08 -0300
Message-ID: <CANx1Pzwm_1GPsF2Q7ruezE7QXi7jSavg5Efkr6j-fcR9DvusPg@mail.gmail.com>
To: Erik Wilde <dret@berkeley.edu>
Cc: public-dwbp-comments@w3.org
Hi Eric,

Thanks again for your message and your explanations! Please, find some more
comments below:

2015-07-28 20:31 GMT-03:00 Erik Wilde <dret@berkeley.edu>:

> hello bernadette.
> thanks for your feedback!
> On 2015-07-28 14:39, Bernadette Farias Lóscio wrote:
>> Thank you very much for your feedback on the DWBP document! Please find
>> some comments below.
>>     - "Best Practice 14: Provide data in multiple formats" might want to
>>     say if that should be done by different URIs, or one URI and HTTP
>>     conneg. that's a very typical question publishers have, so it should
>>     be mentioned at the very least, even if the answer is "we have no
>>     specific recommendation either way".
>> I agree that is important to mention that, however I'm not sure if we
>> should mention this on BP14 or we should mention this in one of the Data
>> Access BP.
> i'll leave it up to you to decide where to best put it, but in my
> experience working with people looking for web architecture guidance, this
> is how the question comes up. they have resources they want to serve in
> multiple formats to make a broader range of consumers happy, and then
> wonder how to best do that.

I agree! I'm gonna discuss this issue with other members of the working
group in order to choose the BP more suitable to explain this.

>      - "Best Practice 14: Provide data in multiple formats" should say
>>     that for fragment identifiers to be consistent across formats, care
>>     is needed to make sure that this is the case (as much as possible,
>>     depending on the formats and their features).
>> I'm sorry, but I don't understand your comment. Could you please give me
>> an example?
> let's say you have time series data in XML and RDF. your dataset has
> fragments that, for example, identify sub-resources of individual days
> (assuming that the whole resource covers weeks or months). only if the
> various representations are carefully desgined to work this way will
> http://example.org/data/week3#day1
> really identify the data fragment of day 1 within the week1 resource. it
> helps consumers, but takes a bit of effort on the provider side. however,
> if planned in advance, the effort is minimal.

In this case, I think you are talking about the identification of resources
that compose a dataset. The identification section [1] has BP for the
identification of datasets and versions of datasets. However, there is no
BP for the identification of resources that compose a dataset. Maybe, we
can include a BP for this. What do you think?

>      - generally speaking, i am wondering why the terms hypertext or
>>     hypermedia are not even mentioned in the spec. isn't that what data
>>     on the web ideally should be, linkable and linked?
>>     https://github.com/dret/webdata#one-star-linkable and
>>     https://github.com/dret/webdata#four-star-linked are core principles
>>     for good web data. *linkable* means more than just URIs. it also
>>     means, for example, to provide meaningful and robust fragment
>>     identifiers for others to link to. *linked* means to use URIs and to
>>     specifically avoid other kinds of (often non-globally scoped)
>>     identifiers, so that links don't break when taken out of context.
>> I agree that data on the Web should linkabe and linked. However, I don't
>> agree that we should talk about hypertext. IMO, the " Web of Data"
>> concerns the creation of links between resources. This happens in the
>> RDF model, for example.
> the web *is* hypertext, so i am a bit surprised that you want to provide
> best practices without mentioning the very foundation. and yes, RDF is
> *one* way to create hypertext, but *only if* people actually use it as
> hypermedia through additional guidelines such as those provided by linked
> data. but RDF is just one example and imho, best practices shouldn't
> prescribe technologies. if people use well-designed XML or JSON hypermedia,
> that's much better than using RDF that's not hypermedia. thus my comment to
> recommend the pattern (hypermedia), and not any specific way how to
> implement it.

I agree with you that best practices shouldn't prescribe technologies. The
DWBP document avoids as much as possible to provide a BP based on one
specific technology. I cited RDF just as an example of how to create links
between resources. However, I still think that creating links between data
resources is different from creating links between text through hypertext.
I'm gonna bring this discussion to the group and we're gonna give you a
feedback about this, ok?

>      - best practices 24 and 27 kind of conflict. one important idea of
>>     REST is to avoid versioning, and having versioned URIs is a pretty
>>     certain sign of bad design smell when it comes to media types and
>>     API design.
>> Considering just BP27, do you agree that we should  "Maintain separate
>> versions for a data API"?
> personally, the "versioning" topic 99% of the time distracts from good web
> or REST. if you do proper versioning, clients don't need to care (because
> of robust extension and openness models). if you "version" so that it's
> breaking and you need to communicate that, then better call it "a different
> API/format", because on technically speaking, you haven't versioned at all
> but simply created a new service/format.
> i think a similar issue has been raised in a parallel thread. good web
> versioning doesn't break things. if things break, very often it's
> misleading to talk about versioning, it's simply to different services that
> have a historical relationship.

I agree that things shouldn't be broken because of versioning, but the idea
of having separate versions for APIs is to avoid problems for consumers
using an older version of the API: "When an API is changed, as opposed to
when the data it makes available is changed, releasing it as a new version
makes it possible to gracefully transition from the old version to the new
one. Keeping the older versions available avoids breaking applications that
cannot be updated."

Could you please help us to propose a better way to solve this problem?


> thanks and cheers,
> dret.
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>            | UC Berkeley  -  School of Information (ISchool) |
>            | http://dret.net/netdret http://twitter.com/dret |

Bernadette Farias Lóscio
Centro de Informática
Universidade Federal de Pernambuco - UFPE, Brazil
Received on Thursday, 30 July 2015 16:08:02 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 30 July 2015 16:08:03 UTC