Re: addressing old comments from Erik W

Hi Caroline,
That's odd, the comments tracker points to an older version for that 
one, and neither 8 nor 18 in that FPWD is about versioning, but neither 
do those two seem enough related to have elicited that remark. I see 
that he did mention those two numbers in an email about versioning 
later, though, so now I think the context info just got entered wrong. I 
think we can call that one addressed now.

But since looking up the old one led me to the fact that we do have 
duplication about use of standard vocabularies, I think we should open a 
new comment, with me as the commenter.

We have two closely related BPs

Use standardized terms

Standardized terms should be used to provide data and metadata

and

Reuse vocabularies

Shared vocabularies should be used to provide data and metadata

The current descriptions don't distinguish the two ideas very clearly. 
Shared vocabularies *are* standardized terms. I think the content in the 
two could be handled in a single BP. I'll also note that GTFS is not 
about terms alone. It's a specification that also requires a specific 
data model. Maybe that's what the second BP about standardization should 
really be about.
-Annette




On 3/8/16 1:26 PM, Caroline Burle wrote:
> Annette, thank you very much!
>
> Based on your comments we updated the table Bernadette created to 
> follow the open comments on the tracker: 
> https://www.w3.org/2013/dwbp/wiki/Comment_tracker_status.
>
> Regarding LC-3051 we think Erik's comments were before this version, 
> where he was talking about BP8 "Provide versioning information" [1] 
> and BP 18 "vocabulary versioning" [2] and this BP was removed. Does 
> you comment regard that or another thing?
>
> Thank you! Kind regards,
> Bernadette, Caroline and Newton
>
> [1] https://www.w3.org/TR/2015/WD-dwbp-20150625/#VersioningInfo
> [2] https://www.w3.org/TR/2015/WD-dwbp-20150625/#VersioningVocabularies
>
> On 03/03/16 17:24, Annette Greiner wrote:
>> 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
>>
>

-- 
Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory