Re: [dwbp] Suggestions to solve the 144 issue (#117)

Hi everyone,

See some comment below:


> I like "...whilst it recommends the use of Linked Data, it also promotes
> best practices for data on the web in formats such as CSV and JSON."
>
> Given the current discussion about things like PDFs, audio files and so
> on, we could extend it event further to say
>
> "...whilst it recommends the use of Linked Data, it also promotes best
> practices for data on the web in formats such as CSV and JSON as well as
> information published for human consumption in documents, audio and video
> files etc."
>

Overall I like the idea, but can't understand why we should put LD on the
top of everything. I really think it is a great technology, but as with any
other technology I also think it has its own purpose and may not be
appropriate for every use case. IMO one can just not say technology X is
the best choice, although we also cover other technologies, because that
will be always a context-dependent choice.

A big -1 to Carlos' comments on "Identifiers not URIs." The Web works on
> URIs. Those are the identifiers we care about. Yes, we have to cope with
> other identifiers - people do love their DOIs and find them useful for
> example - but they're just strings. URIs are defreferencable, other
> identifiers are not (DOIs only become dereferencable if you convert them to
> URIs; Quad Erat Demonstrandum).
>
> So in my view the current text is right, i.e.
>
> Data Identification
> How can unique identifiers be provided for data resources?
> How should URIs be designed and managed for persistence?
>

I don't understand why in the first two saying identifiers is ok for you
but not in the last one.


> There are more comments on URIs later in the doc with which I disagree
> equally strongly. This is the W3C WG on Data on the Web, not data anywhere
> else. If it hasn't got a URI, it's not on the Web and is therefore out of
> scope.
>

I may be explaining myself in a very bad way because I think you are still
not getting my point here even after multiple attempts. Anyway, here I go
one more time:

- My concerns on tech independence have two motivations (1) not being
biassed towards certain technologies because I simply think that would be a
wrong approach and (2) prevent BPs obsolescence due to tech evolution
because I simply think that's a good practice on the basis on my previous
experience with WCAG, the problems we faced with WCAG 1.0 for that and how
we solved them at WCAG 2.0.

- In the case of URIs I totally agree that's the identification system we
use on the web and my motivation in this case is (2)

For example, what if in a near future we have a different ID system in the
web? A quite uncertain scenario, I know, but let's put a more frequent
example, what if one want to use IRIs instead for example? (without needing
to map to URIs first) As currently written you won't be able to use IRIs as
your identification system. Is that what we really want?

On the term 'vocabularies' - I think Antoine answered Carlos well but I'd
> be happy with some sort of expansion, such as:
>
> Data Vocabularies
> How can existing terms, vocabularies and data models be used to provide
> semantic interoperability?
> How can a new vocabulary be designed if needed?
>
> Likewise, Carlos objects to: "... Appropriate security measures should
> also account for secure authentication and use of HTTPS"
>
> HTTPS is the secure protocol on the Web. Anything not HTTP(s) is not on
> the Web and is probably out of scope for W3C.
>

Same case as per URIs. No objection at all to the usage of HTTP(s), but
again other secure authentication protocols may emerge and we are already
coexisting with some others such as WebDAV. Additionally, what about data
that may be described on the web (metadata, etc.) but accessed by other
non-web protocols such as FTP(S)? May we omit such non-Web (but quite
frequent and still Internet based) access methods?


> Overall, Carlos, it seems to me that you're trying to remove the Web
> component altogether. As you'd expect, I strongly disagree.
>

Was not my intention at all. Removing any web component from a data on the
web BPs document will just not make sense for me as well. I hope my real
motivations may be more clear now with the additional clarifications above.


> As we've discussed, data comes in all sorts of formats, but we're
> concerned with using the Web as best as we can - and in many cases that
> *does* mean using LD technologies and/or RESTful APIs that return JSON.
> That is how you do data on the Web and we mustn't be afraid to say so.

If all you're talking about is shifting some bytes from A to B in a process
> that could just as well be completed by exchanging USB sticks then that's a
> perfectly valid operation - but it's not data on the Web.
>

Tend to agree with some nuances. Of course I would love to have everything
in LD/RESTful format on the Web, but at the same time I would like also to
encourage people follow as much BPs as possible even while they may not be
fulfilling all of them. For me encouraging people to use good metadata,
reusable formats, formal data models, open formats, etc. has also a great
value even when may not be finally publishing LD or REST but just XML, CSVs
or the like.

Best,
 CI.




> On 31/03/2015 16:11, Yaso wrote:
>
>> I made several suggestions, although many questions raised by Carlos
>> Iglesias still remains at https://docs.google.com/document/d/
>> 1ecwweAM5t4UVFEjcXnFhXmCUBnRDvwZ1smRLtiKkBEI/edit#
>>
>> If not merged, please submit feedback :-)
>> You can view, comment on, or merge this pull request online at:
>>
>>    https://github.com/w3c/dwbp/pull/117
>>
>> -- Commit Summary --
>>
>>    * Updating doc to solve issues 144 #1 comment from Carlos Iglesias
>>    * Changing URI's by identifiers to solve 144 issue - Carlos Iglesias
>> Suggestion
>>    * Suggesting rewriting to solve 144 issue
>>    * rewriting to solve 144 at 8.8 Sensitive Data
>>    * Suggesting rewriting to solve 144
>>
>> -- File Changes --
>>
>>      M bp.html (28)
>>
>> -- Patch Links --
>>
>> https://github.com/w3c/dwbp/pull/117.patch
>> https://github.com/w3c/dwbp/pull/117.diff
>>
>> ---
>> Reply to this email directly or view it on GitHub:
>> https://github.com/w3c/dwbp/pull/117
>>
>>
> --
>
>
> Phil Archer
> W3C Data Activity Lead
> http://www.w3.org/2013/data/
>
> http://philarcher.org
> +44 (0)7887 767755
> @philarcher1
>
>