- 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. -Annette LC-3061 regarding best practice 30, i am wondering if https://github.com/dret/I-D/blob/master/sunset-header/draft-wilde-sunset-header-00.txt 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.* LC-3059 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* LC-3057 "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.* LC-3058 "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 comments. *Not addressed. Actually that BP doesn’t address the issue raised.And that BP confuses fragment identifiers with reused URIs to refer to entities.* LC-3060 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. LC-3052 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 ecosystems. *Addressed: We now have a BP “Avoid breaking changes to your API”* LC-3051 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