EIDR

The canonical form of an EIDR Content ID is an instance of a handle and has the format:

10.5240/XXXX-XXXX-XXXX-XXXX-XXXX-C

where

• 10.5240 is the DOI prefix for an EIDR asset. The "10" indicates the handle is a DOI; other prefixes are assigned to other asset types (e.g. academic publications). The digits between the "." and "/" form the sub-prefix, which indicates which registration agency within the International DOI Foundation (IDF) has rights to manage these handles. "5240" is assigned to the EIDR Association.
• XXXX-XXXX-XXXX-XXXX-XXXX-C is the DOI suffix. Each "X" denotes a hexadecimal digit (A-F), and "C" is an ISO 7064 Mod 37,36^[1]check digit.

There is also a 96-bit compact binary form that is intended for embedding in small payloads such as watermarks. This form is generated from the canonical format as follows:

• 16-bit sub-prefix: generated by interpreting the sub-prefix as a binary value, e.g. B'0001010001111000'
• 80-bit suffix: the non-checksum part of the suffix, represented as 10 bytes

The Uniform Resource Name form for an EIDR ID is specified in RFC 7302.

For use on the web an EIDR content ID can be represented as a URI in one of these forms:

• https://doi.org/10.5240/XXXX-XXXX-XXXX-XXXX-XXXX-C: this is an EIDR ID represented as a DOI proxy reference (it will be redirected from DOI to the EIDR registry)
• info:doi:10.5240/XXXX-XXXX-XXXX-XXXX-XXXX-C [deprecated]: this is an EIDR ID represented as an RFC 4452 compliant "info" URI (remembering that all EIDR IDs are also DOI IDs, but not the converse).

There are four types of content records, each associated with a reserved prefix:

• Content ID (10.5240/XXXX-XXXX-XXXX-XXXX-XXXX-C): is associated with an entertainment asset such as a movie or TV series. Content records are hierarchical, allowing relationships to be expressed such as a Series, whose children would be Seasons, whose children in turn would be individual episodes. Many other relationships are supported, as described below. Content records form the bulk of the data in the EIDR registry.
• Party ID (10.5237/XXXX-XXXX): identifies entities such as registrants, content producers, and distributors.
• Video Service ID (10.5239/XXXX-XXXX): Identifies a video service, colloquially known as a "channel" or "network": a (usually) linear sequence of content scheduled to be broadcast at specified times (e.g. the Service ID for the Cartoon Network is 10.5239/8BE5-E3F6). Video services are hierarchical: for example, a parent may have several children to account for regional or language variations).
• User ID (10.5238/[0-9a-zA-Z_.#()]{2-32}): Identifies a user using a string of 2–32 alphanumeric and selected special characters (illustrated here with Perl syntax). A User is primarily an administrative concept that is subordinate to Parties (from whom they inherit access rights). Unlike the other EIDR DOIs, the User ID can only be used within EIDR (e.g. programming APIs).

The sub-prefixes 5237, 5238, 5239, and 5240 are all assigned to the EIDR Association.

Content records are objects categorized by their types and relationships. Each has three different (orthogonal) kinds of type:

• Object Type: there are a total of 10 of these. First is the Basic Type, which has the minimal fields necessary to describe a content record. The other 9 are derived from the basic type, and contain extra fields for describing more complex objects.
• Structural Type: these distinguish representations of a work and are listed in increasing order of specificity:
  • Abstraction: Used for objects having no reality, such as a series container or the most basic concept of the original work. This corresponds to the International Standard Musical Work Code (ISWC) for musical works, the International Standard Text Code (ISTC) for textual works, or the International Standard Audiovisual Number (ISAN) for audiovisual works.
  • الأداء : يُستخدم هذا المصطلح للإشارة إلى النسخ الخاصة من العمل، مثل العرض السينمائي الأصلي أو النسخة المُعدّلة للمخرج من فيلم أو نسخة خاضعة للرقابة المحلية من برنامج تلفزيوني. ويتوافق هذا المصطلح تقريبًا مع رمز التسجيل الدولي القياسي (ISRC) للأعمال الموسيقية، ومع بعض استخدامات رمز الإصدار ISAN (V-ISAN) للأعمال السمعية البصرية.
  • رقمي : تمثيل رقمي محدد لعمل ما، مثل ترميز MPEG-2 لفيلم. وهذا يتوافق مع بعض استخدامات V-ISAN.
• نوع المرجع : نوع أصل المحتوى، بغض النظر عن شكل العرض (على سبيل المثال، الفيلم المعروض على التلفزيون لا يزال فيلمًا):
  • السلسلة : تجريد يحتوي على عناصر فردية مرتبة أو غير مرتبة.
  • الموسم : مستوى ثانٍ من التجميع أسفل السلسلة، ويغطي عادةً فترة زمنية
  • التلفزيون : المحتوى الذي ظهر لأول مرة عبر البث التلفزيوني.
  • فيلم : محتوى طويل ظهر لأول مرة في دار سينما أو مسرح.
  • قصير : يتم تعريفه بشكل فضفاض ليشمل عملاً مدته 40 دقيقة أو أقل، مثل مقاطع الفيديو الموسيقية ، أو الأفلام الإخبارية السينمائية ، أو أفلام الرسوم المتحركة القصيرة السينمائية أو الرقمية.
  • الويب : المحتوى الذي ظهر لأول مرة على الويب. وهذا يختلف عن المحتوى الموجود في أماكن أخرى والذي تم نشره على الويب.
  • المواد التفاعلية : هي المحتوى الذي لا يقتصر على المواد السمعية والبصرية فقط. وتشمل قوائم أقراص DVD، والطبقات التفاعلية على شاشات التلفزيون، والمشغلات المخصصة، وما إلى ذلك.
  • التجميع : محتوى يتكون من أصول أخرى متعددة لا يمكن وصفها بدقة أكبر، مثل مجموعة أقراص لسلسلة أفلام.
  • محتوى إضافي : هذا النوع مخصص للمحتوى الثانوي الذي يتمثل غرضه الأساسي في دعم أو إثراء أو الترويج لمحتوى آخر. ومن الأمثلة على ذلك الإعلانات الترويجية، والمشاهد المحذوفة، والأفلام الوثائقية الترويجية ("أفلام صناعة الأفلام").

تتضمن الحقول التالية (المأخوذة من مجموعة أكبر) بيانات الكائن الأساسية لسجل المحتوى:

• النوع الهيكلي : على سبيل المثال التجريد
• النمط : على سبيل المثال، سمعي بصري (لفيلم أو برنامج تلفزيوني)؛ "صوتي" لبرنامج إذاعي؛ "مرئي" لعمل صامت.
• نوع المرجع : على سبيل المثال فيلم
• العنوان : العنوان الرئيسي. يتم التمييز بين العناوين والعناوين البديلة بشكل إضافي من خلال:
  • اللغة : لغة العنوان معبر عنها برمز ISO 639-1
  • التصنيف : إصدار أو إقليمي
• العنوان البديل 1..ن : عنوان بديل واحد أو أكثر (غالباً ما تكون متغيرات إقليمية أو لغوية)
• اللغة الأصلية : لغة الإصدار الأصلي معبر عنها برمز ISO 639-1
• المنظمة المرتبطة 1..N : معرف (معرفات) الطرف للمنتج، الاستوديو، إلخ.
• تاريخ الإصدار : تاريخ إصدار العنوان الأصلي
• بلد المنشأ : رمز ISO 3166-1 alpha 2 ، مع امتدادات للدول التي لم تعد موجودة
• الطول التقريبي : مُعبَّر عنه بصيغة XML Schema xs:duration ^{[ 2 ]} datatype
• المعرف البديل 1..N : معرف واحد أو أكثر مكافئ معبر عنه في نظام معرف أصول مختلف (انظر المناقشة أدناه).
• بيانات العمل : تُقدَّم بيانات عمل مختصرة فقط، تقتصر عادةً على المخرج وأربعة من الممثلين الرئيسيين كحد أقصى. وكما ذُكر، فإنّ هدف نظام EIDR ليس منافسة الأنظمة الاحتكارية التي تُقدِّم بيانات وصفية غنية (مثل ملخصات الحبكة). الهدف الرئيسي هو المساعدة في توضيح العنوان، ودعم جهود التحقق من صحة البيانات وإزالة التكرارات.
• المُسجِّل : الطرف الذي أنشأ سجل المحتوى هذا (على سبيل المثال "10.5237/superparty").
• تاريخ الإنشاء : تاريخ إنشاء سجل المحتوى هذا
• الحالة : عادةً "صالحة" (هناك حالات خاصة للسجلات المحذوفة)
• تاريخ آخر تعديل : آخر مرة تم فيها تغيير سجل المحتوى هذا

يجب أن يكون مُعرّف EIDR قابلاً للحل دائمًا، وبالتالي، في الظروف العادية، يكون سجل المحتوى المقابل دائمًا. هناك آليتان متاحتان للتعامل مع الأخطاء أو الظروف غير الاعتيادية الأخرى. الآلية المُفضّلة هي إعادة التوجيه، حيث يُعاد توجيه مُعرّف EIDR بشفافية إلى سجل محتوى آخر. تُستخدم إعادة التوجيه عادةً للتعامل مع تسجيل أصل مرتين.

الآلية الأخرى هي استخدام سجلات الحذف. تُستخدم هذه الآلية عندما يكون سجل المحتوى تالفًا، أو عند تسجيل أصل غير صالح عن طريق الخطأ. في هذه الحالة، يُعاد تعريف المعرّف بسجل حذف خاص. يمكن للتطبيقات التعرّف على سجل الحذف لأن حقل معرّف EIDR الخاص به يُعيّن إلى القيمة المميزة " 10.5240/0000-0000-0000-0000-0000-X ". لاحظ أن "X" تعني الحرف الرابع والعشرين من الأبجدية اللاتينية ( ASCII 0x58 أو Unicode U+0058).

يُعدّ توفير مجموعة غنية من المعرّفات البديلة للمحتوى أحد الأهداف الرئيسية لـ EIDR. يسمح هذا باستخدام معرّفات EIDR في جميع مراحل سير العمل المتعلقة بالمحتوى؛ فإذا دعت الحاجة إلى معرّف بديل، يُمكن العثور عليه في البيانات الوصفية لمعرّف EIDR. يدعم EIDR تضمين كلٍّ من المعرّفات الخاصة والمعرّفات القياسية الأخرى (مثل ISAN). يُمكن إضافة معرّفات بديلة إضافية عند الحاجة (على سبيل المثال، من قِبل جهات ترغب في دعم سير عمل جديد). فيما يلي مثال على المعرّفات البديلة لأصل EIDR رقم 10.5240/EA73-79D7-1B2B-B378-3A73-M (فيلم Blade Runner ). إذا كان من الممكن تحديد معرّف بديل خوارزميًا، على سبيل المثال عن طريق وضعه بشكل مناسب في عنوان URL للقالب، فإن EIDR يُتيح هذا الرابط.

تُقسّم المعرّفات البديلة إلى معرّفات غير احتكارية ومعرّفات احتكارية. تتميّز المعرّفات غير الاحتكارية بأنواع مُحدّدة مُسبقًا (مثل تلك الصادرة عن ISAN و IMDb وIVA)، بينما المعرّفات الاحتكارية جميعها من نوع "احتكاري"، وتتميّز أيضًا بنطاق DNS مُرتبط بها. اعتبارًا من يوليو 2017، يتوفر أكثر من مليوني معرّف بديل مُباشرةً عبر EIDR.

يمكن ربط عناصر المحتوى ببعضها وفقًا للجدول التالي. تُعبَّر هذه العلاقات كحقول إضافية في سجل المحتوى، وبالتالي فهي نسبية إلى ذلك العنصر. لاحظ أن العنصر المُستَخدَم هو العنصر الفرعي، والهدف هو العنصر الأصل (مثلاً: العنصر المُستَخدَم هو <نوع العلاقة>من العنصر الأصل</نوع العلاقة>). ترد قيود إضافية في الجدول.

Registration of new assets can be done individually or in bulk (up to 100,000 assets at a time). In either case, the workflow comprises a combination of automated (to perform well-defined but tedious tasks) and manual (where human judgment is called for) processes. It is also iterative, as the initial matching process may identify a variety of gaps and errors that need to be dealt with.

Registering new assets is a complex process that requires some preparation, particularly in the case of bulk submission. The automated processes will check syntax, make sure that the basic metadata is supplied, and that any dependencies (e.g. series records created before constituent episodes) are honored. Manual steps include making sure the correct Parties are associated with the asset. One of the most important steps is ensuring that a new asset does not already exist in the registry: this is covered in the next section.

In order to register a new asset a user must be associated with a party that has been granted the "Registrant" role by the EIDR operator. A registrant may be a principal agent, such as a studio or an encoding house, but it may also be a Party doing bulk registration of back-catalogue items, or a Party acting on behalf of someone else. It is also a requirement that a registrant be an EIDR member. In general, content ownership, metadata authority, and registration capability are separate and unrelated concepts.

This refers to flagging assets being submitted to the registry as falling into one of the following three categories:

• Candidate asset is unique (with respect to existing registry assets).
• Candidate asset is a duplicate of an existing record.
• Candidate asset has a high probability of being a duplicate.

This assessment is based on applying a (large) set of rules to the candidate asset, which results a numerical score. Bucketing occurs as the result of comparing the score to two thresholds:

• Low Threshold: any asset with a score below this value is deemed not to be a duplicate. This is the only case when a proposed record addition or modification will succeed.
• High Threshold: any asset with a score above this value is deemed to (almost certainly) be a duplicate. The proposed record addition/modification will not proceed, and an error status will be returned. Registrants will generally use the pre-existing ID for the item they tried to register, and can add missing information and Alternate IDs to the existing record.

Assets falling between the low and high threshold are deemed to have a high possibility of being a duplicate: the proposed record addition/modification will not proceed until manually reviewed by EIDR operations staff.

An EIDR ID is a specialized example of a Digital Object Identifier (DOI), which in turn is built on top of the Handle System developed by the Corporation for National Research Initiatives (CNRI). The EIDR-specific aspects of the lower layers are described in more detail below.

A Digital Object Identifier, standardized as ISO 26324,^[15] seeks to uniquely identify a wide range of digital artifacts including books, recordings, research data, and other digital content. The goal is not just for the IDs to be unique, but persistent and immutable. As opposed to URLs, DOI identifiers stay the same even if the objects move to another location, or become owned by another organization. Here are some of the characteristics of DOI:

• The International DOI Foundation (IDF) enforces previously agreed rules on the constituent Registration Agencies (e.g. EIDR) to ensure continuity. In particular, if an RA ceases operation, the names it hosts will be taken over by another RA.
• The IDF defines rules to which all DOI names must adhere (what kinds of object may be named by a specific RA)
• The DOI system provides a data model, based on a data dictionary, to enable a structured means of expressing metadata (and inter-object relationships).
• The DOI system has its own highly redundant and distributed set of handle and proxy servers.
• All DOI prefixes are of the form "10.NNNN" where 10 is a directory indicator and "NNNN" is a registrant code in the range 1-65535 (e.g. EIDR content records use is 10.5240)

The DOI data model provides the means to associate metadata with each object, as well as policies governing its use. In the words of the DOI Handbook, metadata may include "names, identifiers, descriptions, types, classifications, locations, times, measurements, relationships and any other kind of information related to [an object]." Metadata flows between the following entities:

• Resource Provider: usually the owner of media asset, which is responsible for inputting metadata to the system.
• Registration Agency: the entities that serves as the repository of the assets (and associated metadata). As noted DOI supports a federation of independent RA's, each responsible for a set of assets. EIDR is one such RA. Others include CrossRef for scholarly articles, DataCite for research data, and OPOCE for official publications of the European Union.
• Service User: the entities making queries to RA's retrieve metadata associated with assets. The DOI resolution framework is responsible for dispatching a query to the appropriate RA (the Service User doesn't need to know this).

لتعزيز التوافق بين أنظمة إدارة الأصول، يتبنى نظام DOI مفهوم نواة البيانات الوصفية. وهي مجموعة أساسية من البيانات الوصفية التي يجب أن تتضمنها جميع الكائنات المخزنة ضمن إطار عمل DOI. يمكن الاطلاع على المجموعة الكاملة في دليل DOI. يُعد التوافق موضوعًا واسعًا يتجاوز نطاق EIDR، ولكن المجموعة الفرعية التالية ذات صلة خاصة بأصول EIDR:

• referent: كائن يتم الاحتفاظ به في نظام DOI.
• referentNameاسم المرجع (مثلاً عنوان فيلم)
• primaryReferentTypeبالنسبة لـ EIDR، يشمل ذلك الإنشاء (مثل الأصول الترفيهية) والطرف (مثل منشئها).
• structuralTypeهذه فئات حصرية متبادلة تحدد شكل الأصل. ومن بين الفئات ذات الصلة بأصول EIDR، هناك فئتان: التجريد (كائن مثل فيلم قد يوجد بأشكال متعددة) والأداء (حالة محددة من كائن مثل نسخة المخرج).
• principalAgent: بالنسبة للإبداعات، الكيان المسؤول بشكل أساسي عن وجودها.
• registrationAuthorityCodeيشير الرمز : إلى الوكالة التي أصدرت وثيقة تعريف الأصول (DOI). وهذا ما يُعرف بـ EIDR RA لأصول EIDR.

تتوفر بيانات تعريف EIDR بتنسيق بيانات تعريف DOI القياسي، بالإضافة إلى تنسيقات خاصة بـ EIDR. معرّف DOI لمخطط بيانات تعريف DOI هو doi : 10.1000/276 .

يتم تطبيق نظام DOI بدوره على نظام Handle، وهو خدمة موزعة وقابلة للتوسع بدرجة كبيرة لحل أسماء النطاقات. ويُعرَّف المعرّف (Handle) على النحو التالي:

<Handle>  ::= <Handle Naming Authority> "/" <Handle Local Name>

تُعدّ هيئة التسمية فريدة عالميًا، وتُحدد كلًا من النطاق الإداري وبنية اسم المعرّف المحلي. بالنسبة لـ EIDR في التعريف أعلاه، فإنّ "10.5240" هي هيئة تسمية EIDR، وهي المسؤولة عن تحديد اللاحقة (بما في ذلك ضمان توافقها مع البنية المتوقعة لأصل EIDR). ويُعدّ نطاق هيئات التسمية المسموح بها أكثر عمومية من النطاق المُستخدم في DOI (أو EIDR).

تتيح الطبيعة الموزعة لنظام Handle استضافة كل مساحة اسم محلية على مواقع خدمة متعددة موزعة جغرافيًا. هذا نموذج اتحادي حيث تتمتع كل مساحة اسم محلية بالتحكم الكامل في موقع وتشغيل مواقع الخدمة الخاصة بها. علاوة على ذلك، قد يحتوي كل موقع خدمة على عدة خوادم حلّ: سيتم توزيع الطلبات الموجهة إلى موقع خدمة معين بالتساوي عبر خوادمه المكونة له.

نموذج بيانات نظام المقابض بسيط ولكنه مرن. يمكن ربط عدد غير محدود من القيم بكل مقبض. بمرور الوقت، يمكن إنشاء هذه القيم وتعديلها وحذفها. لكل قيمة من هذه القيم السمات التالية:

• الفهرس : عدد صحيح غير موقع يحدد قيمة البيانات من بين القيم الأخرى التي قد تكون موجودة لهذا المقبض.
• type: a UTF-8 string identifying the type. The type system is extensible and common types are maintained as handles in the "0.TYPE" naming authority. There are no restrictions on the creation of new types, although using resolvable handles as type names is recommended best practice. Common types include URL for a single of indirection, "10320/loc" for a set of context-based resolution alternatives, and various administrative types for Handle System management, all of which are based on handle resolution.
• data: the value itself, represented as a sequence of octets which are interpreted in the context of the associated type
• permission: access rights to this particular value. Note that different data values of a handle may have different permissions
• TTL: an integer that specifies how long a value may be cached
• timestamp: an integer (expressed as milliseconds from the Unix epoch) that records the last time the value was updated
• reference: a list of references to other handle values. These are usually used to add credentials (e.g. a digital signature).

Accessing the Handle System is done via a wire protocol defined in RFC 3652; EIDR applications don't have to be concerned with this because of the layering of protocols.