Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Puede crear cadenas ARK como lo desee, siempre que use solo dígitos, letras (ASCII, sin signos diacríticos) y los siguientes caracteres:

= ~ * + @ _ $ . /

Los dos últimos caracteres están reservados en el caso de que desee revelar relaciones ARK.

Otra característica única de los ARK es que pueden aparecer guiones ('-') pero son inertes de identidad, lo que significa que las cadenas que difieren solo por guiones se consideran idénticas; por ejemplo, estas cadenas

ark:/12345/141e86dc-d396-4e59-bbc2-4c3bf5326152

ark:/12345/141e86dcd3964e59bbc24c3bf5326152

Identificar lo mismo. La razón de esta característica es que los procesos de formateo de texto en el mundo introducen rutinariamente guiones adicionales en los identificadores, rompiendo enlaces a cualquier servidor que trate los guiones como significativos.

Los ARK distinguen entre letras minúsculas y mayúsculas, lo que hace posibles identificadores más cortos (52 vs 26 letras por posición de carácter). Sin embargo, la "forma ARK" es usar minúsculas a menos que necesite ARK más cortos. La restricción hace que sea más fácil para los resolvedores admitir sus ARK en caso de que lleguen del mundo con letras mayúsculas o mixtas, lo que sucede lamentablemente a menudo debido a la suposición persistente de 50 años de que los identificadores no distinguen entre mayúsculas y minúsculas. También puede considerar el uso del repertorio de caracteres de la herramienta Noid, que crea cadenas seguras para la transcripción utilizando el algoritmo más fuerte de dígitos de verificación del identificador principal; utiliza solo dígitos y consonantes menos 'l' (letra ell, a menudo confundida con el dígito 1):

0123456789bcdfghjkmnpqrstvwxz

Con respecto a la asignación, una estrategia común es aprovechar los identificadores heredados. Por ejemplo, un número de muestra de polilla de museo cd456f9_87 podría anunciarse debajo del ark:/12345/cd456f9_87. Es posible que sea necesario modificar algunos identificadores heredados en vista de las restricciones de caracteres ARK. La segunda estrategia común es crear cadenas completamente nuevas para sus ARK. En este caso, es importante considerar si hacerlos opacos o no opacos (o un poco de ambos).

¿Qué son los identificadores opacos?

Las cadenas de identificadores persistentes son típicamente opacas, revelando deliberadamente poco sobre a qué están asignadas, porque los identificadores no opacos no envejecen ni viajan bien. Los nombres de las organizaciones son notoriamente transitorios, razón por la cual los NAAN son números opacos. A medida que se corrigen los títulos y las fechas, los significados de las palabras evolucionan (p. Ej., Los acrónimos más inocentes pueden volverse ofensivos o infractores), las cadenas destinadas a ser persistentes pueden volverse confusas o políticamente desafiantes. La generación y asignación de cadenas completamente opacas también conlleva un riesgo, por ejemplo, los números asignados secuencialmente revelan información de tiempo y las cadenas que contienen letras pueden deletrear palabras involuntariamente (razón por la cual faltan vocales en el repertorio de caracteres recomendado).

...

Las cadenas opacas son "mudas" y, por lo tanto, difíciles de manejar, por eso los ARK fueron diseñados para ser identificadores "parlantes". Esto significa que si hay ARK Identifiers FAQ # metadata, un ARK que llega a su servidor con el '?' la inflexión debería poder hablar de sí misma.

¿Cómo hago que el contenido del servidor sea direccionable con ARK?

Primero, decida cuál será la experiencia del usuario al acceder a sus ARK, por ejemplo, un archivo de hoja de cálculo, un PDF, una imagen, una página de destino llena de metadatos formateados y un rango de opciones, etc. Cualquiera que elija, planifique su servidor para poder responder con metadatos si su ARK debería llegar con un '?' inflexión después de eso.

De lo contrario, servir ARK es como servir URL. Normalmente, las cadenas de URL entrantes direccionan (se asignan) al contenido que devuelve su servidor web. Si su servidor reconoce ARK, los ARK entrantes (expresados ​​como URL) deben asignarse al mismo contenido. Un enfoque común es asignar el ARK a la URL utilizando una tabla de software que actualiza cada vez que cambia la URL. En este caso, su servidor está actuando como un resolvedor local. Si no desea implementar esto usted mismo, existen herramientas y servicios de software ARK que pueden ayudarlo.

Otro enfoque es ejecutar su servidor web sin cambios, pero en lugar de actualizar las tablas locales, actualizaría las tablas de mapeo de ARK a URL que residen en un resolvedor no local. Se pueden encontrar ejemplos de esto entre los proveedores y en cualquier organización que actualice las tablas a través de EZID.cdlib.org (que, debido a una relación especial, actualiza las tablas de resolución en n2t.net).

¿Cómo cito o publicito un ARK?

Se prefiere la forma de URL (https o http) del ARK, por ejemplo,

https://n2t.net/ark:/99166/w66d60p2

Un ARK destinado para uso externo generalmente se publicita (libera, publica, difunde) de esta manera para que sea un identificador accionable. Si se necesita una visualización visual más compacta de un ARK, debe estar hipervinculado; por ejemplo, se puede lograr una visualización compacta de un hipervínculo HTML con

<a href=" https://n2t.net/ark:/99166/w66d60p2 "> ark:/99166/w66d60p2 </a>

Una decisión importante es si sus ARK basados ​​en URL utilizarán el nombre de host de su resolvedor local o el resolvedor N2T.net. Si el control local o el desarrollo de la marca es lo suficientemente importante, anunciaría ARK basados ​​en su resolvedor local (consulte la publicación de contenido con ARK). Si le preocupa la estabilidad de su nombre de host local, anunciaría sus ARK basados ​​en n2t.net (vea ejemplos de ambos).

Resolver sus ARK a través de N2T siempre es posible para los usuarios, independientemente de cómo los anuncie.

...

La mayoría de los ARK son creados por organizaciones que los anuncian ("publican") en función de sus propios resolvedorsresolvedores. Por ejemplo, este ARK se publicó en función del resolvedor ark.bnf.fr :

...

Sí, los ARK se pueden asignar a cualquier nivel de granularidad, como un manuscrito, capítulos dentro de él, secciones de capítulos, subsecciones, etc. Un ARK también se puede asignar a una cosa que encierra otras cosas. En los ARK, el carácter '/' está reservado para ayudar al destinatario a comprender la contención, por ejemplo, el primer objeto a continuación contiene el segundo:

ark:/12148/btv1b8449691v

ark:/12148/btv1b8449691v/f29

Ese es el calificador de contención. Solo hay otro calificador ARK, e indica formas variantes de una cosa usando el carácter reservado ''. delante de un sufijo Por ejemplo, si estos ARK identifican documentos,

ark:/12148/btv1b8449691v/f29.pdf

ark:/12148/btv1b8449691v/f29.html

debido a que difieren solo por el sufijo .pdf o .html, se puede inferir que identifican dos formas diferentes del mismo documento.

...

Las personas necesitan identificadores antes de saber exactamente a qué objeto se refieren, o si se refieren a algo que valga la pena conservar. No se puede crear un identificador que requiera metadatos maduros consolidados durante el desarrollo temprano ya que se sabe poco sobre el objeto. Por lo tanto, los creadores de objetos casi siempre asignan inicialmente identificadores que no tienen requisitos de metadatos, como URL o ARK.

...

No tiene por qué ser costoso. Construir metadatos desde cero puede ser costoso, pero generalmente es creado y administrado por proveedores de objetos, en cuyo caso se puede aprovechar de manera eficiente para los identificadores. Idealmente, para una fuerte persistencia, los metadatos maestros (mantenidos por proveedores de objetos) deberían reflejarse en sistemas independientes, de modo que sea difícil para alguien manipular indetectamente sin detección las asociaciones de identificadores. Por ejemplo, los repositorios de objetos digitales que obtienen ARK y DOI del servicio EZID almacenan una copia de sus metadatos con EZID.cdlib.org, que a su vez almacena otra copia con el resolvedor N2T.net.

¿Qué metadatos se recomiendan para los ARK?

Los metadatos son negocios datos desordenados para todos los identificadores, no solo para ARK. En todos los dominios y tipos de objetos hay miles de estándares, muchos de ellos superpuestos pero conflictivos, y cada uno se aplica de acuerdo con las costumbres organizacionales locales y con diferentes niveles de cumplimiento. Elegir o crear una especificación para sus metadatos depende de factores como

  • si actualmente está administrando metadatos (pista sugerencia: quédese con él a menos que tenga una buena razón para cambiar),
  • si desea publicar objetos oficialmente (pista sugerencia: prepárese para poder proporcionar autor, título, fecha, editor/archivo y tipo de objeto),
  • los requisitos y capacidades de su resolvedor (sugerencia : su personal de TI o proveedor podría tener sus propios requisitos), y
  • si desea almacenar elementos no estándar (sugerencia : N2T lo permite, pero la mayoría de los estándares y proveedores no).

La interoperación interoperatibilidad confiable entre dominios puede permanecer fuera del alcance, pero Dublin CoreDataCiteSchema.org y Dublin Kernel son especificaciones de metadatos comunes a tener en cuenta para su uso con ARK.

...

  • quién   "lo contó" (similar a DC Creator, contributor y Publisher, pero también Inventor, DiscovererDescubridor, Conductor, etc.),
  • qué   se llamaba "tell" (similar a DC Title, pero también TissueSampleNumber, ArtifactBarcode, etc.),
  • cuando   fue "dicho" (Fecha DC similar, pero incluye rangos de fechas, fechas aproximadas y BCE),
  • dónde   se puede encontrar el "relato" (desde DC Identifier, pero generalmente no es necesario porque este es el ARK)

...