Page History

...

Internet2 Trust and Identity's document stewardship process is intended to formalize formalizes the management of documents as they are drafted, proposed, vetted, and approved for use, and published for open access.  It is intended to address any documents that are products of work sponsored by Trust and Identity or one of its community advisory groups. Examples of such products include:

...

• CACTI (Community Architecture Committee for Trust and Identity)
  
• The Trust and Identity Program Advisory Group (PAG)
• Internet2 Trust and Identity executive management
  
• Incommon Technical Advisory Committee (TAC)
• InCommon Community Trust Assurance Board (CTAB)
• InCommon Steering Committee

Getting a Doc ID for a document that will go into the Repository

For a document that will eventually go into the repository, it is recommended to get a document ID and format the document with the needed components during  during the time that you are developing the document, prior to it being finalized. (You will submit the document to go into the repository later when it has been finalized and approved.)

• Contact the librarian, ti-librarian@internet2.edu, to get the document repository ID and Persistent URL (which is based on the DOI).  ( The document will not be placed in the repository and the Persistent URL will not be active until a later stage when the document is final and approved.)
• Follow the steps below to add the needed elements to the document.

Preparing a Document

...

for the Repository

To prepare a document to go into the Document Repository:

...

Note: You obtain the Repository ID and Persistent URL from the librarian. Also note that the The authorized Sponsors are listed in Trust and Identity Document Stewardship. See Document Repository Metadata Element Definitions for more information.

https://share-my-id.orcid.org/ is a useful tool for collecting ORCIDs for a group of authors.

2. This copyright and licensing info must be on the first page of the document  (where <year> is the current year).

See example HERE  3. When the document

Submitting a Document to the Repository

These steps must be completed before a document is ready to go into the repository.

1.  Document review phase is complete

...

2.  A community consultation has been completed if

...

1. appropriate 
2. The sponsor has approved the final version (please see note above on this page about need for InCommon Steering approval of documents sponsored by TAC and CTAB) 

Once these steps are done, send the , then the document is ready to be put in the repository.
Send the document to  ti-librarian@internet2.edu  in both of these formats:

1. text (preferred) or HTML

2. PDF, unless that is not appropriate for the specific document

You may also submit the revisable (e.g., MS Word) document that was used to create the PDF/text/HTML documents for inclusion in the Development Location metadata element. (See below.) This is recommended if future revisions may be made.

At this time, you may also propose the following metadata elements to the librarian, as appropriate:

...

An updated document is a new document with its own new row in the document repository, even though much of its content may be the same as the original document. 
Just as with the original document, the update is subject to review and approval, as specified by its sponsor.

There are a few of things to note:

• The Repository ID of the original document will be listed as a "superseded document" on the superseding document's repository metadata page.
• The "Deprecated" field of original document's repository metadata page will be "yes."
• Numbering: When the superseding document is an update to the superseded document, its Repository ID will typically be the Repository ID of the original document after adding 1 to the version number. For example, an update to TI.22.3 would have TI.22.4 for its Repository ID. There are, however, exceptions to this numbering convention.  For example, the superseding document may be completely new, not an update, or there may simply be historical reasons why this was not done,
• There are additional details for the Doc Repostiory Librarian at  https://spaces.at.internet2.edu/x/Y5iTBg 

...

• Note that a revisable version of the older document may be available in the Development Location field of its repository metadata page, as well as other material that may help you.

The "Deprecated" field of a document's repository metadata page will be set to "yes" when its content should no longer be trusted to reflect current practice or thinking on its topic. As noted above, this occurs when a document is superseded by another, but it can also occur without a superseding document

Here is an example of a document that is an update to an earlier document in the repository. http://doi.org/10.26869/TI.105.2

Note the change log at the end of the document, which is a helpful feature to add to any such document. http://doi.org/10.26869/TI.105.2

When it's time to deprecate a document

In that, in order to maintain a historical record, documents are never removed from the repository, unless they were placed in error. Documents that no longer have anything other than historical interest are deprecated.

Here is an example of a deprecated document http://doi.org/10.26869/TI.105.1

Documents that are presented elsewhere in Internet2's or InCommon's website

Typically, references to documents in the repository should link to the documents' metadata pages via their DOI URL (e.g., http://doi.org/10.26869/TI.105.1).

There are times, however, when a document should be presented in a manner that is consistent with the context of the referring page, or when multiple references to the document make link maintenance difficult as new versions of the document are published. This alternative presentation is usually accomplished by creating a copy of the document's text, images, etc. within the platform used to present the referring page (e.g., WordPress for http://www.incommon.org).

See this example.

When a document in the repository is also presented on a webpage, the content "owner"  (note July 1, 2019: we may want to link from here a list of content owners and these pages) of the referring page should:

• Preface the copy with a statement clarifying that it is not the authoritative copy, and providing a link to the authoritative copy in the repository.  For example,
  • This document is curated under the Internet2 Trust and Identity Document Stewardship program. Download the official text from the Internet2 Trust and Identity Document Repository at http://doi.org/10.26869/TI.34.1.
• Do not change the text or otherwise change the intellectual integrity of the document.  If you find you need to do this, you should probably be creating a new document with (perhaps extensive) quoting from the authoritative copy.
• Keep the formatting as close to the authoritative content as practical.
• Ask the librarian to add a note to the metadata page to indicate that a non-authoritative copy exists, its URL, and who (by name or position) should be informed if the document is superseded or deprecated. For example,
  • A non-authoritative copy of this document is presented by Internet2 at https://www.incommon.org/federation/baseline-expectations-for-trust-in-federation/. Please inform the InCommon Service Manager if this document is ever superseded or deprecated so that the non-authoritative copy can be corrected or removed.

Additional Info

Working group chair and flywheel guidelines with regard to the Document Stewardship process are found here.

Please contact David Walker <dwalker@internet2.edu> or Emily Eisbruch <emily@internet2.edu> for Jessica Fink <jfink@internet2.edu> for more information.

Document Stewardship Process - Framework Docs

...