W3C home > Mailing lists > Public > public-dwbp-wg@w3.org > March 2016

addressing old comments from Erik W

From: Annette Greiner <amgreiner@lbl.gov>
Date: Thu, 3 Mar 2016 12:24:16 -0800
To: DWBP Public List <public-dwbp-wg@w3.org>
Message-ID: <56D89D70.8070807@lbl.gov>
Hi folks,
Further to the agenda item of closing old DWBP comments, I've collated 
the comments from Erik Wilde so that we can discuss them. My thoughts on 
each are added in bold.


regarding best practice 30, i am wondering if

is something that might be worth mentioning in some form. this is
currently a pre-I-D draft, but maybe the general idea of communicating
resource availability is relevant for DWBP?

*Not addressed. Something to consider adding to the doc, if it’s stable.*


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.

*Partially addressed. We don’t talk about fragment identifiers. I 
suggest we add it. This relates to LC-3058 and LC-3051*


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

*Not addressed. We mention URIs and conneg in the API versioning BP, but 
not in the discussion of multiple formats. I suggest we add it.*


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

PROPOSED RESOLUTION: Best Practice 12: Use persistent URIs as 
identifiers within datasets 
(https://www.w3.org/TR/dwbp/#identifiersWithinDatasets)addresses this 

*Not addressed. Actually that BP doesn’t address the issue raised.And 
that BP confuses fragment identifiers with reused URIs to refer to 


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.


when it comes to versioning, i am always recommending to focus on
openness and extensibility and have robust and well-defined models for
those (this almost always requires well-defined processing models for
data). this often avoids the need for versioning, which when done badly
will be a breaking change.

when it comes to versioning, it is important to distinguish between
breaking and non-breaking versioning changes. this comes down to the
comment above: good openness and extensibility makes it easier to have
non-breaking versioning, which helps tremendously in decentralized

*Addressed: We now have a BP “Avoid breaking changes to your API”*


what is the difference between "Best Practice 8" and "Best Practice
18" (reuse vocabularies)? it seems that they are very similar, and if 
there indeed is a
subtle difference, maybe create one practice that spans both, or make it
more clear what the difference is?

*Still an issue: We now havea BP “use standardized terms”, which talks 
about standards for nonURIs, like country codes, and also URIs, like for 
acoustic tracking systems. We also have a BP “use persistent URIs as 
identifiers within datasets”.*

Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory
Received on Thursday, 3 March 2016 20:24:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 March 2016 20:24:49 UTC