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

> > So, proposal is to change the description of requirement R-
> PersistentIdentification from:
> >
> >                  Data should be persistently identifiable
> > To
> >                  An identifier for a particular resource should be
> resolvable on the Web and associated for the foreseeable future with a
> single resource or with information about why the resource is no longer
> available.
> >
> > My opinion is that the second description, while richer and more
> informative, is straying into Best Practice territory, as opposed to a
> requirement.
>
> Slightly, yes. But the issue of resolvability is part of the requirement
> IMO.

+1


> The alternative would be to have a separate requirement for that,
> but this seemed like the simplest approach?
>
 If we do a separate requirement for resolvability we will end up having
non resolvable thing tied up with a resolver (DOI, etc)... best to stick
with the text Phil proposed.


Christophe


> Phil
>
>
>   A requirement should define the end goal, not how to achieve it, or?
> >
> >
> >
> > Cheers,
> >
> > Deirdre
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Makx Dekkers [mailto:mail@makxdekkers.com]
> > Sent: 01 October 2014 18:03
> > To: Manuel.CARRASCO-BENITEZ@ec.europa.eu; phila@w3.org;
> public-dwbp-wg@w3.org
> > Subject: RE: dwbp-ISSUE-46 (PIDs): How should we handle the issue of
> persistent URI design? [Use Cases & Requirements Document]
> >
> >
> >
> > Can I suggest we drop this discussion in the group? I'd love to do some
> free-style wresting (conceptually, not physically) sometime, off-list, over
> these issues that are close to my heart (me being squarely in the 'forever'
> camp), but I don't think we can get any further than the text Phil
> suggested earlier:
> >
> >
> >
> > R-PersistentIdentification
> >
> >
> >
> > An identifier for a particular resource should be resolvable on the Web
> and associated for the foreseeable future with a single resource or with
> information about why the resource is no longer available.
> >
> >
> >
> > Makx.
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >
> >> From: Manuel.CARRASCO-BENITEZ@ec.europa.eu<mailto:
> Manuel.CARRASCO-BENITEZ@ec.europa.eu> [mailto:Manuel.CARRASCO-
> >
> >> BENITEZ@ec.europa.eu<mailto:BENITEZ@ec.europa.eu>]
> >
> >> Sent: Wednesday, October 01, 2014 5:02 PM
> >
> >> To: phila@w3.org<mailto:phila@w3.org>; public-dwbp-wg@w3.org<mailto:
> public-dwbp-wg@w3.org>
> >
> >> Subject: RE: dwbp-ISSUE-46 (PIDs): How should we handle the issue of
> >
> >> persistent URI design? [Use Cases & Requirements Document]
> >
> >>
> >
> >> Phil,
> >
> >>
> >
> >>> "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 ;-)
> >
> >>
> >
> >> # Tomas
> >
> >> The intention must be *forever*, though it will eventually disappear:
> >
> >> it is a matter of policy
> >
> >> ##
> >
> >>
> >
> >>    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).
> >
> >>
> >
> >> # Tomas
> >
> >> Agree. This is the reason why in COMURI:
> >
> >>   -  "The approach is syntactic and it does not specifies the semantics
> >
> >> of the URI ..."
> >
> >>   - Direct identification of variants
> >
> >>   - Direct identification of metadata
> >
> >>
> >
> >> For example:
> >
> >> http://example.com/foo           # landing page
> >
> >> http://example.com/foo.zip     # direct identification of data
> >
> >> http://example.com/foo?         # metadata
> >
> >> ##
> >
> >>
> >
> >>>
> >
> >>> 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).
> >
> >>
> >
> >> # Tomas
> >
> >> I did not expressed clear enough. Though URI should be forever, this
> >
> >> wonderful URI weather service disappear and some kind people archive
> >
> >> it into:
> >
> >>   http://archive.org/example.com
> >
> >>
> >
> >> The original data was produce dynamically by the "foo-weather" system
> >
> >> behind the server and (for whatever reason) to run "foo-weather" in
> >
> >> the archival server is not possible. Hence, it would be hard to get
> >
> >> the data.
> >
> >>
> >
> >> Archiving data is challenging, but it is a child game in comparison to
> >
> >> maintain running legacy programs; this happen event to the experts :-)
> >
> >>
> >
> >>    -  Third World Wide Web Conference  1995 - 19 years ago : where is
> >
> >> the data?
> >
> >>    -  http://info.cern.ch - about 23 years ago: try to run the original
> >
> >> server ##
> >
> >>
> >
> >>>    - 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.
> >
> >>
> >
> >> # Tomas
> >
> >> Good example: we need "Magna Carta URIs" :-) Can be justify not to aim
> >
> >> forever?
> >
> >> The URI is a component of long-term data preservation. It might useful
> >
> >> to look at
> >
> >>     http://www.ietf.org/rfc/rfc4810.txt
> >
> >> ##
> >
> >>
> >
> >>>    - 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)
> >
> >>
> >
> >> # Tomas
> >
> >> True: we talk most of the time about URI but in fact one should be
> >
> >> referring to URL.
> >
> >> ##
> >
> >>
> >
> >>>    - 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).
> >
> >>
> >
> >> # Tomas
> >
> >> True. What is in scope?
> >
> >> The data preservation (online and offline archiving ) was taken into
> >
> >> account in COMURI because the email exchange a few months ago.
> >
> >> COMURI, URI, URL, is probably the smallest part.
> >
> >> ##
> >
> >>
> >
> >> Phil
> >
> >>
> >
> >> Regards
> >
> >> Tomas
> >
> >>
> >
> >>
> >
> >>> -----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<mailto: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
> >
> >
> >
> >
>
> --
>
>
> Phil Archer
> W3C Data Activity Lead
> http://www.w3.org/2013/data/
>
> http://philarcher.org
> +44 (0)7887 767755
> @philarcher1
>
>


-- 
Onderzoeker
+31(0)6 14576494
christophe.gueret@dans.knaw.nl

*Data Archiving and Networked Services (DANS)*

DANS bevordert duurzame toegang tot digitale onderzoeksgegevens. Kijk op
www.dans.knaw.nl voor meer informatie. DANS is een instituut van KNAW en
NWO.


Let op, per 1 januari hebben we een nieuw adres:

DANS | Anna van Saksenlaan 51 | 2593 HW Den Haag | Postbus 93067 | 2509 AB
Den Haag | +31 70 349 44 50 | info@dans.knaw.nl <info@dans.kn> |
www.dans.knaw.nl


*Let's build a World Wide Semantic Web!*
http://worldwidesemanticweb.org/

*e-Humanities Group (KNAW)*
[image: eHumanities] <http://www.ehumanities.nl/>