Re: dwbp-ISSUE-46 (PIDs): How should we handle the issue of persistent URI design? [Use Cases & Requirements Document]

On 01/10/2014 13:31, Manuel.CARRASCO-BENITEZ@ec.europa.eu wrote:
> Dear WG members,
>
> Comments to several posting.
>
> "URI persistence is a matter of policy ..."  -  http://www.w3.org/TR/webarch/#URI-persistence
>
> Having restated this, data should be identifiable *forever* - not for foreseeable future.

True, but no one can make promises forever, only for the foreseeable 
future ;-)

  URI syntax is a different matter: one can put up with almost any 
syntax as long as it can identify the data.

And there's a can of worms. The identifier may identify the data, or it 
may identify a landing page about it or something else (and some 
communities don't understand the difference and glaze over when you try 
and say it's important).

>
> One has to assume that "web-based" means accessed with HTTP(S), so this implies that the data is always accessible with HTTP(S)  and in the *same* environment: this is not the case. For example, data accessible with:
>
>   - HTTP(S): data can be archived without the original environment - dynamic data will not be accessible

Huh?

http://example.com?service=weather&date=today

dynamic data can certainly be returned from a URI (which takes us back 
to a discussion we had ages ago about URIs being APIs).

>   - FILE: no server side processing - dynamic data will not be accessible

More true.

>
> The real world is far nastier.

Very true.

>
> In a nutshell:
>
>   - Long-term.- Think in at least 25 to 50 years: data must readable, and hence also identifiable

If we can justify those figures (or any other), I'd be happy to include 
them. The UK National Archives reckons it can't promise beyond the next 
5 years although it plans for its URIs to be as persistent as the 
original Magna Carta that it houses.

>   - Simple.- Keep it very simple - minimal processing (this includes URI redirections) to get the data

Ideally yes. But URIs that are not URLs will need to return something 
and that might be a 303 redirect (and PLEASE let's not open up 
HttpRange-14 today... or any otehr day)

>   - Full life-cycle.- original site, archiving into archival sites, and offline data - http://dragoman.org/comuri.html#ultrapersistent-uri

Bear in mind my issue here is about phrasing the requirements that the 
WG needs to meet (whether by COMURI, the BP doc, the vocabs or anything 
else).

Phil



> -----Original Message-----
> From: Data on the Web Best Practices Working Group Issue Tracker [mailto:sysbot+tracker@w3.org]
> Sent: Wednesday, October 01, 2014 9:47 AM
> To: public-dwbp-wg@w3.org
> Subject: dwbp-ISSUE-46 (PIDs): How should we handle the issue of persistent URI design? [Use Cases & Requirements Document]
>
> dwbp-ISSUE-46 (PIDs): How should we handle the issue of persistent URI design? [Use Cases & Requirements Document]
>
> http://www.w3.org/2013/dwbp/track/issues/46
>
> Raised by: Phil Archer
> On product: Use Cases & Requirements Document
>
> As of 2014-10-01, the UCR does not explicitly call for advice on URI design/design for persistence. It is, however, implied in R-PersistentIdentification which says "Data should be persistently identifiable."
>
> Do we need to add any detail to this? Or an additional requirement? Or do we think we've covered it?
>
> Context is all. In W3C space, persistent identifier means persistent URI. For some communities, that doesn't match the culture (scientific publishing for example).
>
>
>

-- 


Phil Archer
W3C Data Activity Lead
http://www.w3.org/2013/data/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Wednesday, 1 October 2014 13:10:57 UTC