- From: Leigh Dodds <leigh@ldodds.com>
- Date: Fri, 5 Sep 2014 11:21:02 +0100
- To: Manuel CARRASCO-BENITEZ <Manuel.CARRASCO-BENITEZ@ec.europa.eu>
- Cc: Steven Adler <adler1@us.ibm.com>, public-dwbp-wg <public-dwbp-wg@w3.org>
Hi, (Hopefully constructive!) Comments below: On Fri, Sep 5, 2014 at 10:57 AM, <Manuel.CARRASCO-BENITEZ@ec.europa.eu> wrote: > Dear Leigh, dear Steven, > > 1. URI > Rephrasing from the a URI point of view. What should be the recommendation on these options? > > Path : http://data.europa.eu/foo > Domain : http://foo.europa.eu > > Let's forget for now about service, collection, API, etc. Governments already set-up "official data servers": this is an issue, and as already commented, is *not* an academic one. Without further context, both seem perfectly valid to me. Both have their own advantages and disadvantages. > 2. Organisation structure > Out internal consensus is to avoid reflecting the internal organisation in URIs due to frequent changes. Agreed. > 3. Comuri > Your comments are welcome. Specification is about making concrete decisions. Stating the obvious, we are not producing laws that people must follow: they will follow specifications they find useful. > > By the way, some specifications become laws when parliaments say so :-) Again, in my personal opinion, this working group would be better delivering a "URI Scheme Best Practices" document that recommends some general best practices for defining consistent URI schemes and which discusses the available options for achieving them, rather than a specification that attempts to define a single URI scheme. A best practices document would provide useful support for people wanting to publish data to the web and benefit from the experience of others. There are existing documents in this space which could be used as input, so there is experience to draw on. There are features in the Comuri specification which, if useful, might be worth defining as a separate specification. For example it *might* be useful to standardise a extension of HTTP content negotiation that specifies a way to use URL parameters and/or path components to perform negotiation in conjunction with existing HTTP options. That is one feature of the scheme you define. That specification could then be implemented by people building web frameworks, etc. But that seems like something that is out of scope for this group. Cheers, L. -- Leigh Dodds Freelance Technologist Open Data, Linked Data Geek t: @ldodds w: ldodds.com e: leigh@ldodds.com
Received on Friday, 5 September 2014 10:21:32 UTC