the indecs analysis Godfrey Rust Data Definitions London

the <indecs> analysis Godfrey Rust, Data Definitions, London W 3 C DRM workshop, January 2001 <indecs> January 2001

the <indecs> analysis <indecs> project 1998 -2000 <indecs> framework 2000 EDIt. EUR IFPI CISAC societies IFRRO societies DOI Foundation Muze Inc book industry record industry copyright owners identification, resolution of content largest Web content data provider <indecs> January 2001

the <indecs> analysis Output “Principles, model and data dictionary, June 2000” www. indecs. org Scope DRM as a metadata problem. Current applications – description, not DRM yet EDIt. EUR/ONIX metadata standard (books, e. Books, video? audio? ) DOI Foundation Metadata framework for DOI apps Muze Inc Basis of new multimedia products <indecs> January 2001

Scope make People Stuff is used by do about Deals <indecs> January 2001

Key entities Parties Creations Agreements Need to identify and describe these three things in controlled ways <indecs> January 2001

Axioms (things we can’t avoid) 1. Intellectual property is complex 2. Metadata is critical 3. Metadata is modular 4. Metadata is interdependent 5. Transactions need automation <indecs> January 2001

Granularity, modularity Is. Identifier. Of A Is. Creator. Of Is. Agreement. About B C D Is. Content. Of Is. Identifier. Of H Is. Creator. Of Is. Agreement. About Is. Date. Of E Is. Party. To F Is. Party. To G I J K <indecs> January 2001

Interoperability=automated recognition Is. Identifier. Of A Is. Creator. Of Is. Agreement. About B C D Is. Content. Of Is. Identifier. Of H Is. Creator. Of Is. Agreement. About Is. Date. Of E Is. Party. To F Is. Party. To G I J K <indecs> January 2001

Principles (guidelines to follow) 1. Functional granularity (when is a thing? ). DRM standards to support any level of granularity. 2. Unique identification (what is it? ) 3. Designated authority (who says its true? ) 4. Appropriate access (what do I need you to know? ) Balance of access, security and privacy. <indecs> January 2001

The metadata landscape for “creations”

The metadata landscape for “creations” Libraries Archives Museums Education Technology Newspapers Magazines Standards Journals Books Texts Audiovisual Audio Music Copyright

1980 s The metadata landscape for “creations” Libraries Archives Museums Education MARC Technology Newspapers UPC EAN Magazines ISSN Standards ISO codes ISBN Journals Books Texts Audiovisual CAE Audio Music Copyright

The metadata landscape for “creations” Libraries MARC Technology Archives Museums IMS Education IIM FRBR Dublin Core UPC url urn Handle Multimedia mid 90’s Newspapers EAN Standards DOI Magazines ISSN ISO codes ISBN ISRC Audio ISMN Music CIS Books Texts ISWC Audiovisual ISAN Journals CAE Copyright

today The metadata landscape for “creations” Libraries MARC Technology XML schema EBooks e. Books MPEG 7 Multimedia Archives FRBR RDF ISO 11179 url uri Handle urn MPEG 21 Museums CIDOC IMS Education IIM NITF LOM Dublin Core Newspapers UPC Standards ISO codes Audiovisual ISAN SMPTE RIAA/IFPI ISRC Audio DOI ISMN Music ISSN SICI EPICS Journals Books BICI ISTC Texts ISWC CIS ISBN ONIX Xr. ML IPDA PRISM Magazines CROSSREF <indecs> P/META UMID abc EAN CAE Copyright

Convergence All serious schemes are becoming. . . EPICS/ONIX (“books”) Granular (parts and versions) SMPTE (audiovisual) Modular (creations within creations) OEBF (e. Books) Multimedia Multinational Multilingual Multipurpose RIAA/IFPI (audio/music) MPEG 7 DOI genres CIDOC (museums/archives) MARC/FRBR (libraries) Dublin Core CIS (copyright societies) NITF (newspapers) PRISM (magazines) Result: major “sector” schemes are now trying to define metadata with broadly the same scope, only different emphases.

Three indecs conclusions 1. All metadata is just a view 2. (Almost) all terms need unique identification 3. Events are the key to interoperability <indecs> January 2001

#1: All metadata is just a view eg an identifier for a “journal article” may refer to. . . A manuscript The abstract work A draft A (class of) physical copy in a publication A (class of) digital copy (not in a publication) A (class of) digital copy in a publication A (class of) digital format A specific digital copy A (class of) paper copy A specific paper copy An edition A reprint A translation etc…and many combinations of the above Similar views apply to other types of creation. Three <indecs> conclusions <indecs> January 2001

#1: All metadata is just a view Views must not be confused: mistaken identity can be disastrous for rights management Increasingly, views need to be interoperable within organizations (eg production workflow, rights, marketing) and – in future – in Web transactions. The need for automated, interoperable views in dcommerce will become enormous. Three <indecs> conclusions <indecs> January 2001

#2: (Almost) all terms need identifiers Values must be defined and identified (what do you mean by an abstract work? an edition? a format? a scholar? a book? a name? ) So views need comprehensive standardized vocabularies. Automation needs disambiguity. Terms of rights must be unambiguous. Anything may be a term of an agreement. Emergence of the value of structured ontologies and directories for commerce. Three <indecs> conclusions <indecs> January 2001

Standardised vocabularies Existing… Territories, Language, Currency, Date/Time (ISO) Measures (U. C. U. M) Needed… Creation types (manifestation, expression, abstraction…) Derivation types (adaptation, sample, compilation…) Contributor roles (author, translator, cameraman…) User roles (distributor, copier, viewer, translator…) Title types (abbreviated, inverted, formal. . . ) Name types Identifier types Media types (formats) Media property types (encoding, features) Tools/instruments etc. . . and many identifiers not yet established or devised (Parties, Agreements, ISWC, ISTC, ISAN, UMID etc) <indecs> January 2001

#3: Events are the key to interoperability Most metadata is “stuff” or “people” based. Web metadata interoperability may best be achieved by describing “events”. This interoperability may not be established at source but by intermediation (data transformations). Event descriptions are also the key to rights metadata. Three <indecs> conclusions <indecs> January 2001

Resource description DRM Subject G Rust Creator 21. 1. 01 Time Ealing Place This ppt Creating <indecs> January 2001

Event description This ppt output DRM input G Rust agent 21. 1. 01 context Ealing context Creating <indecs> January 2001

Creating event This ppt output DRM input G Rust agent 21. 1. 01 context Ealing context Creating E 1 <indecs> January 2001

Using event This ppt input N Paskin agent 2. 2. 2001 context New York context Showing E 2 <indecs> January 2001

Using event This ppt output E 1 input N Paskin agent 2. 2. 2001 context New York context Showing E 2 <indecs> January 2001

Complex event This ppt output N Paskin agent XYZ context E 1 Showing E 2 <indecs> January 2001

Complex event This ppt output N Paskin agent XYZ context E 3 context E 1 Showing E 2 1 -3. 2. 2001 New York ? ? ? <indecs> January 2001

Transforming event This ppt output E 1 E 4 Adapting N Paskin E 3 agent E 2 output His ppt context Next week context Oxford <indecs> January 2001

Agreement N Paskin agent G Rust agent Last night context The bar context Agreeing E 5 <indecs> January 2001

Agreement output N Paskin agent G Rust agent Last night context The bar context E 4 Adapting Agreeing E 5 output E 2 Showing <indecs> January 2001

Permission permission N Paskin agent G Rust agent Last night context The bar context E 4 Adapting Agreeing E 5 permission E 2 Showing <indecs> January 2001

Requirement N Paskin payer G Rust payee Last night time The bar place Paying E 6 input $50 <indecs> January 2001

Completed agreement This ppt input E 1 permission N Paskin party G Rust party Last night The bar E 4 Agreeing E 5 Adapting Paying E 6 requirement time place XYZ permission E 2 Showing E 3 <indecs> January 2001

Assertion B Bolick agent 21. 1. 01 context S. A. Asserting E 7 output context assertion E 5 Agreeing <indecs> January 2001

Completed agreement This ppt input E 1 permission N Paskin party G Rust party Last night The bar E 4 Agreeing E 5 Adapting Paying E 6 assertion requirement time place permission E 2 Showing place XYZ E 3 E 7 Asserting <indecs> January 2001

Barriers to DRM (Digital Rights Management) systems at present are B 2 C for “unitary” rights: doesn’t deal well with B 2 B and modularity (“stuff is complex”). Holdup 1: Rights vocabularies need descriptive vocabularies and identifiers - not yet ready. Holdup 2: Events model is needed to integrate descriptions and rights - event-based tools not yet developed. 2001+ before mature interoperable developments start to emerge. <indecs> January 2001

the <indecs> analysis Godfrey Rust, Data Definitions, London W 3 C DRM workshop, January 2001 <indecs> January 2001