<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2141 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC3339 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml">
<!ENTITY RFC6068 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6068.xml">
<!ENTITY RFC8141 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8141.xml">
]>
<!--3986-->

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-pwid-urn-specification-00" ipr="trust200902"> 
 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN" 
    they will automatically be output with "(if approved)" -->

 <!-- ***** FRONT MATTER ***** -->

 <front>
   <!-- The abbreviated title (attribute abbrev="The pwid URN definition") is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->

   <title>A Persistent Web IDentifier (PWID) URN Namespace</title>

   <author fullname="Eld Maj-Britt Olmuetz Zierau" initials="E.M.O.Z." role="editor"
     surname="Zierau">
     <organization>The Royal Danish Library</organization>
     <address>
       <postal>
         <street>Soeren Kierkegaards Plads 1</street>
         <code>1219</code>
         <city>Copenhagen</city>
         <region></region>
         <country>Denmark</country>
       </postal>
       <phone>+45 9132 4690</phone>
       <email>elzi@kb.dk</email>
       <!-- uri and facsimile elements may also be added -->
     </address>
   </author>

   <date year="2017" month="December"/>

   <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
        in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

   <!-- Meta-data Declarations -->

   <area>General</area>

   <workgroup>Internet Engineering Task Force</workgroup>
   <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>pwid, persistent identifier</keyword>
   <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
     <t>This document specifies a Uniform Resource Name (URN) for Persistent Web IDentifiers to web material in web archives 
       using the 'pwid' namespace identifier. The purpose of the standard is to support general, global, sustainable, humanly 
       readable, technology agnostic, persistent and precise web references for web materials.</t>
     <t>
       The PWID URN can assist in two ways: First, by providing potential resolvable precise and persistent reference 
       scheme for documents, which is not sufficiently covered by existing web reference practices. Second, by 
       providing a standardized way to specify web elements in a web collection also known as web corpus. Definitions of web collections are often needed 
       for extraction of data used in production of research results, e.g. for evaluations in the future. 
       Current practices today are not persistent as they often use some CDX version,
       which vary for different implementations.</t>
   </abstract>
 </front>

 <middle>
   <section title="Introduction">
     <t>The purpose of the PWID URN is to represent general, global, sustainable, humanly readable, technology 
       agnostic, persistent and precise web archive resource references - in a way that can be used for technical solutions.
     </t>
     <t>
       The motivation for defining a PWID namespace is the growing challenge of references to web resources,
       - both regarding referencing web resources from papers and regarding definition of web collection/corpus - calls for action now, which can be provided with 
       PWID as a URN, allthough the prefixing with "urn:" is not ideal. In deatail the challenges are:
     </t>
     <t>
     <list style="symbols">
       <t>Citation guidelines generally do not cover general and persistent referencing techniques for web resources that are not registered by Persistent Identifier systems (like  
         <xref target="DOI">DOI</xref>). However, an increasing number of references point to resources that only exist on the web, e.g. blogs that turned out to have a historical impact. 
         In order to obtain persistency for a reference, the target need to be stable.  As the live web is 'alive' and in constant change, persistency can only be obtained by referring to 
         archived snapshots of the web. The PWID URN is therefore focused on referencing archived web material in a technology agnostic way (research documented in <xref target="IPRES"></xref>
         and <xref target="ResawRef"></xref>).
       </t>
       <t>There are many different requirements for construction of collection definitions for web material besides precision and persistency. Recent research have found that various legal and 
         sustainability issues leads to a need for a collection to be defined by references to the web parts in the collection. The PWID URN is needed in such definitions in order to 
         fulfil these 
         requirements and to enable a collection to cover web materials from more archives (Research documented in and <xref target="ResawColl"></xref>).
       </t>
     </list>   
     </t>
     <t>For the sake of usability and sustainability, the definition of the PWID URN is focused on only having the minimum required information to make a precise identification of 
       a resource in an arbitrary web archive. Resent research have found that this is obtain by the following information <xref target="ResawRef"></xref>:
     </t>
     <t>
       <list style="symbols">
         <t>Identification of web archive</t>
         <t>Identification of source:
           <list style="symbols">
             <t>Archived URI or identifier</t>
             <t>Archival timestamp</t>
           </list>
         </t>
         <t>Intended coverage (page, part, subsite etc.)</t>
       </list>   
       The PWID URN represents this information in an unambiguous way, and thus enabling technical solutions to be defined in this URN. 
     </t>

     <section title="Requirements Language">
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
     </section>
   </section>

   <section title="Namespace Registration Template">
     <t>Namespace Identifier:
       <list style="empty">
         <t>PWID</t>
       </list>
     </t>
     <t>Version:
       <list style="empty">
          <t>1</t>
       </list>
     </t>
     <t>Date:
       <list style="empty">
           <t>2017-12-08</t>
       </list>     
     </t>
       
     <t>Registrant:
       <list style="empty">
         <t>
           Eld Maj-Britt Olmuetz Zierau<vspace></vspace>
           The Royal Danish Library<vspace></vspace>
           Soeren Kierkegaards Plads 1<vspace></vspace>
           1219 Copenhagen<vspace></vspace>
           Denmark<vspace></vspace>
           ph: +45 9132 4690<vspace></vspace>
           email: elzi@kb.dk<vspace></vspace>
         </t>
       </list>     
     </t>

     <t>Purpose:
       <list style="empty">
         <t>
           The purpose of the PWID URN is to represent general, global, sustainable, humanly readable, technology 
           agnostic, persistent and precise web archive resource references - in a way that can be used for technical solutions. 
           The standard is needed to address web materials meeting precision and persistency issues on par precision in
           with traditional references for analogue material.
           <vspace></vspace><vspace></vspace>
           The scope and applicability of the PWID URN is both references to archived web resources from literature as well as basis for defining parts of a archived web collection. 
             Strict unambiguous syntax is needed in order to ensure that it can be used 
             for computational purposes. This is relevant for web collection definitions, which will need a strict syntax in order to be a basis for automatic extraction. 
             Furthermore, readers of research papers are today expecting to be able to access a referenced resource by clicking an actionable URI, therefore a similar facility 
             will be expected for references to available archived web material.  
           <vspace></vspace><vspace></vspace>
            The interest for this new PWID has already been shown, a paper about the invention of the PWID "Persistent Web References - Best Practices and New Suggestions" 
             <xref target="IPRES"></xref> was accepted for the iPres 2016 conference and nominated as best paper. At the RESAW 2017 conference there are two related papers: One on referencing 
             practices <xref target="ResawRef"></xref> and one on research data management practices <xref target="ResawColl"></xref>. The interest for the PWID 
             so far indicates that this is a recognized issue, and that the PWID can fill a gap.
           <vspace></vspace><vspace></vspace>
           The PWID URN is to represent this information in a way that can be used for technical solutions, for example for resolving of a references and automatic 
             extraction of web collection defined by PWID URNs <xref target="ResawRef"></xref> <xref target="ResawColl"></xref>. 
             There may come different implementations for resolving which may rely on different protocols and application. As a start there is work on a prototype that can work for the Danish 
             Netarkiv data and open web archives with standard patterns for the current technologies. Further work will be done to make this more internationally integrated. 
           <vspace></vspace><vspace></vspace>
           The ambition is to make the PWID URN namespace definition a constituent part of a standard being developed in the IETF or
           some other recognized standards body. The textual version of the PWID (see additional information) is already in draft of the revision of the ISO 690 reference standard.
          </t>
       </list>     
     </t>
     
     <t>Syntax:
       <list style="empty">
           <t>The syntax of the PWID URN is specified below in Augmented Backus-Naur Form (ABNF) <xref target="RFC5234">RFC 5234</xref> 
             and it conforms to URN syntax defined in 
             <xref target="RFC8141">RFC 8141</xref>. The syntax definition of the PWID URN is:
           </t>
           <t>
             <figure>
               <artwork align="left">
                 pwid-urn  = = "urn" ":" pwid-NID ":" pwid-NSS 
               </artwork>
             </figure>     
           </t>
           <t>      
             <figure>
               <artwork align="left">
                 pwid-NID = "pwid"
                 pwid-NSS = archive-id ":" archival-time ":" coverage-spec 
                 ":" archived-item
               </artwork>
             </figure>     
           </t>
           <t>      
             <figure>
               <artwork align="left">
                 archive-id  = +( unreserved )
               </artwork>
             </figure>     
           </t>
           <t>      
             <figure>
               <artwork align="left">
                 archival-time   = full-date datetime-delim full-pwid-time
                 datetime-delim  = "T"
                 full-pwid-time  = time-hour [":"] time-minute [":"] time-second "Z"
               </artwork>
             </figure>     
           </t>
           <t>      
             <figure>
               <artwork align="left">
                 coverage-spec    = "part" / "page" / "subsite" / "site" 
                 / "collection" / "recording" / "snapshot"
                 / "other"
               </artwork>
             </figure>     
           </t>
           <t>      
             <figure>
               <artwork align="left">
                 archived-item = URI / archived-item-id
                 archived-item-id  = +( unreserved )
               </artwork>
             </figure>     
           </t>
           <t>
             where 
             <list style="symbols">
               <t>'unreserved' is defined as in <xref target="RFC3986">RFC 3986</xref></t>
               <t>'coverage-spec' values are not case sensitive (i.e. "PAGE" / "PART" / "PaGe" / ... are valid values as well.)</t>
               <t>'archival-time' is a UTC timestamp conforming to the W3C profile ISO8601 <xref target="ISO8601">ISO 8601</xref> (also defined in <xref target="RFC3339">RFC 3339</xref>), 
                 with a few exception. It has to be a UTC timestamp in order to conform with web archiving practices, which always uses UTC in order to avoid confusions. 
                 The 'full-date' is defined as in <xref target="RFC3339">RFC 3339</xref>. The 'archival-time' must represent the time specified in the archive, and can therefore be specified 
                 at any of the levels of granularity as described in <xref target="W3CDTF"></xref> and in accordance with teh WARC standard <xref target="ISO28500">ISO 28500</xref>.
                 <vspace></vspace><vspace></vspace>In line with <xref target="RFC3339">RFC 3339</xref> the "T" may alternatively be lower case "t".
                 <vspace></vspace><vspace></vspace>'time-hour', 'time-minute' and 'time-second' are defined as in <xref target="RFC3339">RFC 3339</xref>.
                 <vspace></vspace><vspace></vspace>In line with <xref target="RFC3339">RFC 3339</xref> the "Z" may alternatively be lower case "z".</t>
               <t>'URI' is defined as in <xref target="RFC3986">RFC 3986</xref></t>
             </list>
           </t>
           <t>The 'coverage-spec' defines the type of archived item, serving as a precision to what is referred:
             <list style="symbols">
               <t>part<vspace></vspace>
                 the single archived element, e.g. a pdf, a html text, an image
               </t>
               <t>page<vspace></vspace>
                 the full context as a page, e.g. a html page with referred images
               </t>
               <t>subsite<vspace></vspace>
                 the full context as a subsite within its domain, e.g. a document represented in a web structure
               </t>
               <t>site<vspace></vspace>
                 the full context as a site within its domain
               </t>
               <t>collection<vspace></vspace>
                 a collection/corpora definition, e.g. defined as descibed in <xref target="ResawColl"></xref>
               </t>
               <t>snapshot<vspace></vspace>
                 a snapshot (image) representation of web material, e.g. a web page 
               </t>
               <t>recording<vspace></vspace>
                 a recording of a web browsing
               </t>
               <t>other<vspace></vspace>
                 if something else
               </t>
             </list>
           </t>
         <t>
           Note that the 'coverage-spec' is a parameter that could have been specified as a query. However, since the 'pwid-urn' can include an URI as 'archived-item', it would introduce 
           ambiguities if the 'coverage-spec' was specified as a query, since it would not be clear whether the query belonged to the 'pwid-urn' or the 'archived-item'.
         </t>
       </list>     
     </t>
     
     <t>Assignment:
       <list style="empty">
         <t>
           There are no authorities for assigning PWID URNs to resources, as the rule is the it is the given by the syntax that the name is assigned according to the 
           <list style="symbols">
             <t>Identification of web archive</t>
             <t>Identification of source:
               <list style="symbols">
                 <t>Archived URI or identifier</t>
                 <t>Archival timestamp</t>
               </list>
             </t>
             <t>Intended coverage (page, part, subsite etc.)</t>
           </list>   
           Therefore, the PWID
           URNs are created independently, but following an algorithm that itself guarantees uniqueness.
           <vspace></vspace><vspace></vspace>
           The name will always be unique, as the only way to define a clash would be that a web archive cease to exist, and by time another web archive gets the same name space 
           and have resources with the same name and same archiving timestamp, but with different contents. This is a highly unlikely scenario. 
         </t>
       </list>     
     </t>
     
     <t>Security and Privacy:
       <list style="empty">
         <t>Security and privacy considerations are restricted to accessible web resources in web archives. If resolvers to PWID URNs are created, there should be made an 
           analysis of whether they can be restricted to the former mentioned registry of web archives. Security and privacy will then be a question of security and privacy 
           considerations related to the web archive resources.
         </t>
       </list>     
     </t>
     
     <t>Interoperability:
       <list style="empty">
         <t>This is covered by comments in the Syntax description, where the 'archival-time' conforms to the W3C profile <xref target="ISO8601">ISO 8601</xref> (also defined in <xref target="RFC3339">RFC 3339</xref>) 
           and use of date conforms to the WARC standard <xref target="ISO28500">ISO 28500</xref> using UTC dates only. 
           Furthermore, the when the 'archived-item' is a URI, this conforms to the URI standard defined as in <xref target="RFC3986">RFC 3986</xref>.
           </t>
       </list>     
     </t>
     
     <t>Resolution:
       <list style="empty">
         <t>
           The information in a PWID URN can be used for locating a web archive resource, for any kind of web archive. It includes the minimum information for web archive materials, 
             which enables resolvability, manually or by a resolver. The plan is to develop a resolving service, but this is only in a prototype form at the moment.
             
           <vspace></vspace><vspace></vspace>
           Resolution of a PWID URN is the primary motivation of making a formal URN definition, instead of just textual representation of the for needed parts of a PWID:
             <list style="symbols">
               <t>Web archive identification<vspace></vspace>to find the archive holding the material
               </t>
               <t>Archived URI or identifier of item<vspace></vspace>as part of identifying the material
               </t>
               <t>Date and time associated with the archived URI/item <vspace></vspace> as part of precise identification of the material
               </t>
               <t>Coverage of what is referred <vspace></vspace> as part of clarification of what the referred material covers (page, part etc.)
               </t>
             </list> 
              in the following the different resolution techniques are explained (manual as well as via a service) 
           
              An example of a PWID URN is:
             <list hangIndent="10" style="empty">
               <t>urn:pwid:archive.org:2016-01-22T11:20:29Z:page:http://www.dr.dk</t>
             </list> 
             has the information:
             <list style="symbols">
               <t>archive.org<vspace></vspace>
                 currently known identifier in form of the Internet Archive domian name for their open access web archive </t>
               <t>2016-01-22T11:20:29Z <vspace></vspace>
                 UTC date and time associated with the archived URI </t> 
               <t>page<vspace></vspace>
                 clarification that the reference cover the full web page with all its inherited parts selected by the web archive</t>
               <t>http://www.dr.dk<vspace></vspace>archived URI of item </t>
             </list>
             
             With knowledge of the current (2017) Internet Archive open access web interface having the form:
             <list hangIndent="10" style="empty">
               <t>https://web.archive.org/web/&lt;time&gt;/&lt;uri&gt;</t>
             </list>
             We can manually (or technically) deduce an actual (current 2017) access https address:
             <list hangIndent="10" style="empty">
               <t>https://web.archive.org/web/20160122112029/http://www.dr.dk</t>
             </list>
             and regard the referred web page as the reference.
           <vspace></vspace><vspace></vspace>
           The same recipe can be used for other Wayback platforms - and possibly also other web archive access tools platforms, as the crucial information is date and 
             URI, which are requested to be looked up in a specified archive.
           <vspace></vspace><vspace></vspace>
           Note that this also includes access to archives that are only accessible via a local proxy to a restricted environment. 
             Here the difference is that the archive information is used to identify the local environment used (possibly on-site) and then construct local http/https 
             address based on knowledge from the local access installation. In November there was created a prototype for PWIDs to the Netarkivet, and there are plans to extend it. 

           <vspace></vspace><vspace></vspace>
           Automatic access of a referenced web resource may work on the open net for open web archive or in restricted environments for the closed web archives. 
             There may be a need for varied operation depending on the available technology and applications, e.g.: 
             <list hangIndent="10" style= "symbols">
               <t>Via locally installed browser plug-ins or applications forming http/https URIs:
                 <list hangIndent="10" style= "symbols">
                   <t>http/https URIs for standard web archive interfaces <vspace></vspace>
                     At this stage there are initiatives on streamlined and  standardize APIs to web archives interfaces, - and in case such APIs will be implemented generally, 
                     it may be used for resolving of the PWID URNs. This could be on form (denoting pwid parts in &lt;&gt; using syntax names):
                     <list hangIndent="10" style="empty">
                       <t>https://&lt;archive-id&gt;/pwid?time=&lt;archival-time&gt;&amp;coverage=&lt;coverage-spec&gt;&amp;item=&lt;archived-item&gt;</t>
                     </list>
                     The example from previous section would then resolve by
                     <list hangIndent="10" style="empty">
                       <t>https://archive.org/pwid?time=2016-01-22T11:20:29Z&amp;coverage=page&amp;item=http://www.dr.dk</t>
                     </list>
                   </t>
                   <t>http/https URIs for archive material for individual web archives <vspace></vspace>
                     Using the current open access http/https address pattern for the individual web archives, which for the example is  
                     <list hangIndent="10" style="empty">
                       <t>https://web.archive.org/web/20160122112029/http://www.dr.dk</t>
                     </list>
                     This would require a registry of the different patterns for the individual web archives
                   </t>
                 </list>
               </t>
               <t>Via web research infrastructures
                 this is a future solution scenario as a web archive research infrastructure do not yet exists.
                 However, it is a likely future scenario, as it is currently being proposed in the RESAW community <xref target="RESAW"></xref>. 
                 The PWID URN resolving could in such cases be a question of starting a special application, as for the 'mailto' scheme <xref target="RFC6068">RFC 6068</xref>.
               </t>
             </list>
         </t>
       </list>     
     </t>
     
     <t>Documentation:
       <list style="empty">
         <t>
          None relevant
         </t>
       </list>     
     </t>
     
     <t>Additional Information:
       <list style="empty">
         <t>
           The PWID was orininally suggested as a URI based on research between a computer science researcher with know of web archiving and researchers from humanity subject (History and Literature).
           This resulted in the paper "Persistent Web References - Best Practices and New Suggestions" 
           <xref target="IPRES"></xref>  from the iPres 2016 conference. In this paper the PWID is referred to as WPID. However, one of the feedbacks has been a concern that 
           WPID was interpreted as a PID related to a PID-system, e.g. as the DOI. All though PID does not have a precise definition that makes it wrong to call it a "WPID.
           The danger is that it is confused with PID systems, which is not the intension. Consequently, this suggestion names the PWID instead. 
           <vspace></vspace><vspace></vspace>
           The comments on the drafted PWID URI (<xref target="DraftPwidUri"></xref>) has been that is seems to be a URN rather than a URI. Which is the reason why it is now suggested as a 
           URN, although there is a danger that users of the reference style can be confused by the the additional "urn:" prefix.
           <vspace></vspace><vspace></vspace>
           At the RESAW 2017 conference there are two related papers: One on referencing 
           practices <xref target="ResawRef"></xref> and one on research data management practices <xref target="ResawColl"></xref>. This practice is also planned to be used for Danish web collections.
         </t>
       </list>     
     </t>
     
     <t>Revision Information:
       <list style="empty">
         <t>This is the initial version of PWID as a URN</t>
       </list>     
     </t>
   </section>
   
   <section anchor="Acknowledgements" title="Acknowledgements">
     <t>A special thanks to Caroline Nyvang and Thomas Kromann who have contributed to the research identifying the minimum information required in a persistent web reference, and to 
       Bolette Jurik contributed with supplementary research concerning requirements for web collection/copora definitions.  Also thanks to all that have contributed to this work with the research and 
       reviewing this RFC.</t> 
   </section>

 </middle>

 <!--  *****BACK MATTER ***** -->

 <back>

   <references title="Normative References">
     &RFC3986;
     
     &RFC2119;
     
     &RFC5234;
     
     &RFC3339;
     
     &RFC8141;
   </references>

   <references title="Informative References">
     <reference anchor="IPRES" target="http://www.ipres2016.ch/frontend/organizers/media/iPRES2016/_PDF/IPR16.Proceedings_4_Web_Broschuere_Link.pdf">
       <front>
         <title>Persistent Web References - Best Practices and New Suggestions</title>
         <author initials="E." surname="Zierau">
           <organization>The Danish Royal Library</organization>
         </author>
         <author initials="C." surname="Nyvang">
           <organization>The Danish Royal Library</organization>
         </author>
         <author initials="T. H." surname="Kromann">
           <organization>The Danish Royal Library</organization>
         </author>
         <date year="2016" month="October"/>
       </front>
       <annotation>In: proceedings of the 13th International Conference on Preservation of Digital Objects (iPres) 2016, pp. 237-246</annotation>
     </reference>
     
     <reference anchor="DraftPwidUri" target="https://datatracker.ietf.org/doc/draft-pwid-uri-specification/">
       <front>
         <title>DRAFT: Scheme Specification for the pwid URI, version 3</title>
         <author initials="E." surname="Zierau">
           <organization>The Danish Royal Library</organization>
         </author>
         <date year="2017" month="December"/>
       </front>
     </reference>

     <reference anchor="DOI" target="https://web.archive.org/web/20161020222635/https:/www.doi.org/">
       <front>
         <title>The DOI System</title>
         <author>
           <organization>International DOI Foundation</organization>
         </author>
         <date year="2016" />
       </front>
       <annotation>pwid:archive.org:2016-10-20_22.26.35:site:https://www.doi.org/</annotation>
     </reference>
     
     <reference anchor="ResawRef" target="https://archivedweb.blogs.sas.ac.uk/files/2017/06/RESAW2017-NyvangKromannZierau-Capturing_the_web_at_large.pdf">
       <front>
         <title>Capturing the Web at Large - a Critique of Current Web Referencing Practices</title>
         <author initials="C." surname="Nyvang">
           <organization>The Danish Royal Library</organization>
         </author>
         <author initials="T. H." surname="Kromann">
           <organization>The Danish Royal Library</organization>
         </author>
         <author initials="E." surname="Zierau">
           <organization>The Danish Royal Library</organization>
         </author>
         <date year="2017" />
       </front>
       <annotation>In: proceedings of the RESAW 2017 Conference, DOI: 10.14296/resaw.0004</annotation>
     </reference>

     <reference anchor="ResawColl" target="https://archivedweb.blogs.sas.ac.uk/files/2017/06/RESAW2017-JurikZierau-Data_management_of_web_archive_research_data.pdf">
       <front>
         <title>Data Management of Web archive Research Data</title>
         <author initials="B." surname="Jurik">
           <organization>The Danish Royal Library</organization>
         </author>
         <author initials="E." surname="Zierau">
           <organization>The Danish Royal Library</organization>
         </author>
         <date year="2017" />
       </front>
       <annotation>In: proceedings of the RESAW 2017 Conference,  DOI: 10.14296/resaw.0002</annotation>
     </reference>
     
     <reference anchor="RESAW" target="https://web.archive.org/web/20170529113150/http://resaw.eu/">
       <front>
         <title>A Research infrastructure for the Study of Archived Web materials</title>
         <author>
           <organization>The Resaw Community</organization>
         </author>
         <date year="2017" />
       </front>
       <annotation>pwid:archive.org:2017-05-29_11.31.50Z:site:http://resaw.eu/</annotation>
     </reference>

     <reference anchor="ISO8601" target="https://www.iso.org/standard/40874.html">
       <front>
         <title>Data elements and interchange formats -- Information interchange -- Representation of dates and times</title>
         <author>
           <organization>International Organization for Standardization</organization>
         </author>
         <date year="2004" />
       </front>
     </reference>

     <reference anchor="ISO28500" target="https://www.iso.org/standard/68004.html">
       <front>
         <title>Information and documentation -- WARC file format</title>
         <author>
           <organization>International Organization for Standardization</organization>
         </author>
         <date year="2017" />
       </front>
     </reference>
     
     <reference anchor="W3CDTF" target="http://www.w3.org/TR/NOTE-datetime">
       <front>
         <title>Date and Time Formats: note submitted to the W3C. 15 September 1997</title>
         <author>
           <organization>W3C</organization>
         </author>
         <date year="1997" />
       </front>
       <annotation>
         W3C profile of ISO 8601
         pwid:archive.org:2017-04-03_03.37.42Z:page:http://www.w3.org/TR/NOTE-datetime
       </annotation>
     </reference>

     &RFC2141;
     
     &RFC6068;
      
   </references>

   <!-- Change Log
v00 2017-06-09  EMOZ  Initial version
   -->
 </back>
</rfc>
