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

Re: some comments on the DWBP draft

From: Erik Wilde <dret@berkeley.edu>
Date: Tue, 28 Jul 2015 16:31:58 -0700
Message-ID: <55B810EE.1020909@berkeley.edu>
To: public-dwbp-comments@w3.org
CC: Bernadette Farias Lóscio <bfl@cin.ufpe.br>
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.

>     - "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


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.

>     - 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.

>     - 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.

thanks and cheers,


erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |
Received on Tuesday, 28 July 2015 23:32:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 28 July 2015 23:32:52 UTC