Re: My review of the DWBP 21st Jan editor's draft

Hi Phil,

some more comments inline:


> [...]
>
> Personally I agree that re-users is better than consumers but the
> consensus in the WG so far has been consumer.


I think re-users is not only the most frequent term in the data world for
this, but also the one that conveys a more natural meaning in general.


- "A basic knowledge of vocabularies and data models would be helpful to
>> better understand some aspects of this document." would replace this for
>> "A
>> basic knowledge of some specific technologies could also be helpful to
>> better understand certain implementation techniques of this document."
>>
>> In general I would try to keep all literature technologically-neutral with
>> the exception of the content of the implementation sections.
>>
>
> It depends on your POV. I like the term data model but Bernadette argues
> that it means something different in the context of an RDB although I think
> it's worth thinking about. Vocabularies typically have a UML-like diagram.
> The important thing about DCAT, for example, is the distinction between a
> dataset and a distribution. Whether you use dcat or schema.org terms is
> less important IMO. But this is a WG discussion point.


Agree that the key point is the model. Not care too much about the final
denomination provided that it is neutral, something I think vocabs is not.



> [...] "How should URIs be designed and managed for persistence?" (should
>> be "How
>> should IDs be designed and managed for persistence?"
>>
>
> No. ID schemes other than URIs are not on the Web and therefore out of
> scope. Welcome to W3C.


Totally agree, my concern is not the content but the place. All titles from
BPs must be technologically neutral. The place for talking about specific
techs is implementation, not the title. I agree URIs is the only
implementation we have for the Web so far, still that should go in the
implementation section not in the title. As the BPs template reads "This
represents the best advice available at the time of writing but specific
circumstances and future developments may mean that alternative
implementation methods are more appropriate to achieve the intended
outcome" that's why it is very important to keep the rest of the sections
in the BP (and specially the title) technologically agnostic.



> [...]
>
>
>> - I would think twice about including a "data archiving" phase, as it is
>> usually considered not a good practice to make things disappear from the
>> web (with some exceptions maybe)
>>
>
> This has been discussed (at TPAC and since IIRC). We talk only about the
> Web aspects, such as redirects, proper HTTP response codes etc. Actually I
> think we can sharpen up that advice perhaps with 303 and 410 codes etc. But
> that's a BP I'm currently looking at for a variety of reasons and will have
> a modified version to offer later.


I think most of current 7.11 Data preservation BPs go way beyond the web
aspects you mention and need more discussion and consensus.



> [...]
>>
>> - I don't know why we haven't added also JSON or XML as possible (and
>> frequent) implementations for this.
>>
>
> That would be useful. Care to suggest some text and links? (I'm trying to
> help the editors get this done in a bit of a hurry).


Did a pull request for this.



> - Description of the possible implementation is not about using standard
>> terms but about using self-descriptive formats and that should be part of
>> a
>> different BP - see also my separated email on BP2 and (deleted) BP4. We
>> should focus here on providing a list of well-known reference metadata
>> element sets that are widely used (i.e. dc; dcat; foaf...)
>>
>
> OK, again, suggested text would be helpful.


Did another pull request for this.


BP5-BP6
>>
>
>> - Is there any reason for not to provide a more complete list of terms in
>> the implementation sections? (e.g. all those from DCAT)
>>
>
> Brevity and readability. We have referred to DCAT a lot, what we're
> highlighting here is that it covers both discovery and admin aspects.
>

Good, but as currently looks like those may be the only "mandatory" ones.
Should add a more explicit note about those been only examples then.