1. eSciDoc – Content model requirements
Natasa Bulatovic
Max-Planck Digital Library
Fedora Architecture Summit,

2. Contents eSciDoc content types overview
eSciDoc Contents – basic requirements
Building blocks of eSciDoc contents
CModel proposal
Examples
CModel additional issues

3. eSciDoc content types overview - contents
Name
Description
Category
Scope
Publications
Articles, Books, Reports, Conference Proceedings etc.
Item
eSciDoc
Scholarly Workbench items
Images, translations, transcriptions, bundles, collections
Item, container
Annotations
textual annotations, audio-visual annotations, image annotations
Digital editions, compilations
MPG Yearbook, MPG Yearbook, Scientific reports, Subject specific collections
Bibliographic references
Bibliographic references (ref.database)
Language feature
A language feature and description
WALS
Language feature values
Values of language features for the World Atlas of Languages

4. eSciDoc content types – master data
Name
Description
Type Scope
Organizational Units
Organizational units master data (name, description, home page, contacts etc.)
eSciDoc
Contexts
Administrative units for content items and content containers
XML Schemas
XML schemas needed for various purposes
Persons
Authority data on persons (?)
Languages
List of languages (support for various linguistic projects)
WALS
Vocabularies
Controled vocabularies (thesauri, classifications, domain values)

5. (eSciDoc) CModel – basic requirements
To define:
Category (item, container, master data)
Relation types (and how they are validated and created, versioning info for relation types)
Versioning/Revisioning setup (how new revisions affect related objects)
Default layout templates for objects of a particular type
MIME types allowed for content components Other, eSciDoc specific properties
Mechanism to specify content type specific properties (e.g. workflow, statuses, additional info)

6. eSciDoc – types of relations (RELS-EXT)
Content Relation types
Table of contents, References, Annotations, Translations, Transcriptions
Relation of the item to the Administrative context
Structural Relation types
Parent-child relations between container and item/container
NOT: relations between metadata record object and binary content object
Navigational Relation types
Between an eSciDoc content item and anything else that can be an „actionable“ link (another PID, web-service etc.)
Relation ontology is defined by user for specific types of content item
Relations have metadata (relation properties)
Relations have versioning info
Relations and access rights?

7. Content container/item - example
Metadata, licenses, identifiers
Scholarly
Workbench
Collection
Image I1 (*)
Bundle B1
Image I2 (*)
Image I1
Image I2
Content relations
Annotation A1
Transcription T1
Structural relations
Image I1 (*)
Bundle B2
Transcription T1 (*)

8. eSciDoc contents – building blocks
Metadata
record
Item? Container? Object? Digital Object? Fedora Objects?
Database tables? Database table rows/columns?
Content components
Content relations
Structural relations

9. CModel - proposal

10. CModel – what it can specify?
Composites
Metadata
record
Content components
Relations
Content relations
Structural relations
CObject
Formally described with a CModel

11. CModel – compositional relations (RELS-INT?)

12. CModel and graphs
Proposal: Fedora to support „TOC“ functionality i.e. getting the graph info for:
CModel (describe what objects of this type can contain – CModel „native“ disseminator)
CObject (describe what this particular cobject contains)

13. CModel – cObject – Fedora Object

14. CModel – additional issues
Disseminators -> Moving towards CMDA
CMDA „oportunistic“-> CFormatModel?
CModel and inheritance (multiple CModels?)
CModel and physical storage info?

15. Examples – type specific properties
<custom-properties>
<property name=”pubitem.status”
matchpattern=”pending|submitted|released|withdrawn”
optional=false default=”pending”/>
<property name=”qa_status”
matchpattern=”accepted|not accepted”
optional=false default=”not accepted”/>
</custom-properties>

16. Example – Composites part
<composites ordered=”true”>
<component label=”MD” minOcc=”1” maxOcc=”1” version-rule=” WOV”>
<!— version-rule {WOV|default|none} 
<allowed-formats>
<format mime=”text/xml” uri=”pronom:fmt/111”>
<format mime=”text/html” uri=”pronom:fmt/96”>
</allowed-formats>
</component>
<component label=”PubFile” minOcc=”0” maxOcc=”unbounded” type=”Info:fedora/cmodel:pubfile” version-rule=” WOV”/>
<component label=”AdminComments” minOcc=”0” maxOcc=”unbounded” version-rule=” none”>
<!— would be nice to state against which schema to validate (schema, relaxNG, compaxt… - schemas themselves would be objects 
</composites>

17. Examples - Relations <relation baseOnt=”uri:eSciDocOntology”
id-name=”hasMember”
minOcc=”0”
maxOcc=”unbounded”
targetType=”cmodel:pubitem”
version-rule=”floating”/>
<relation baseOnt=”uri:WALSOntology”
targetType=”cmodel:wals-language”