DCMI Architecture: Metadata Entities and Relationships Dublin Core 8 Workshop National Library of Canada, Ottawa Eric Miller, Dan Brickley, Rael Dornfest,
(Re)Discovery zDCMI – Making it easier to find things using the web zExamples: yFind me all the documents about the subject woodworking yFind me all the documents about the subject woodworking created by any person with a name of Stu
What weve learned… zExperience from dc-usage zIdentified pitfalls with describing people, organizations, etc. in terms of documents that they create, publish, edit, etc. zProblems relate to discovery, description and reusability zImportant to recognize that documents, people, organizations, etc. are independent (and as such have independent characteristics) but indeed are related.
Problematic Example zDc.contributor.illustrator.organization.postcode yQuestion: Is the postcode of the organization that the illustrator works for a characteristic of the document? yAnswer: no! zBut… we want/need to be able to represent this for discovery (DCMI mission)
Grounded in Discovery zFinding documents requires describing documents zFinding documents requires describing people zFinding education-related documents requires describing additional characteristics of those people and documents…
Problems and Implications zFocus on describing information resources to the exclusion of other resources zOverloading the description of information resources zResults in yHard to partition working group activity yHard to effectively discover across metadata yNo coherent extensibility mechanism yInteroperability across independent extensions next to impossible
Recognition zInformation Resource (Entity) zAgent Resource (Entity) zRelations between them (e.g. creator, publisher, editor, etc.) zEntities have descriptions zAgent yAssociated characteristics (name, etc.) zOther Entities
Architecture zHistory of difficulties yDC-usage committee didnt endorse any of the proposed qualifiers for agents yDC-usage couldnt effectively move forward without additional extensible, modular principles zArchitecture is required yStructure, qualification, versioning, multiple languages, domain-extensions: complexity! zAgent Working Group may be the first of many zArchitecture has to work for all
Information Resource Agent Resource Information Resource Event Resource Subject Resource
Landscapes and Architecture zHelp with the conceptual view of DCMI activities and how things fit together zFacilitate the design of Lego's zSupport the notion of making complex statements out of simple sentences. yThe development of Lego Themes zThe design of common, simple principles
The benefits… zOf common, simple principles yEnable all groups building legos to snap together without a central process/authority structure yStrictly pragmatic requirements… we cant afford weekly teleconferences of cross working group activities yRaels Why palm pilots work analogy zMinor inconvenience for major benefits
Architectural Considerations zSupport the descriptive spectrum ySimple literal value ySyntactically including structured values yDirect reference of resources xDDC, LAF, TGN, etc. yDefault values zFocus more on the lego interfaces among resources zPractical, pragmatic focus on discovery… back to basics… Making it easier to find things using the web
Scope and Complexity zHow many types of entities and relationships are we talking about? zDCMI scope yGround questions in a context of the original mission yFinding things using the web zFinding and describing are bound together
Dan Brickley XML Tutorial Dan Brickley The resource has an identifier of The Resource has a title of XML Tutorial. The resource is created by a person. The person has a name of Dan Brickley. The person has an address XML Tutorial title creator name
Lego Example, RSS and DC A Story Macintosh OS OS: Macintosh
Where do we go from here… zLego Architecture supports the initiative zWe dont have an entire solution zBut we have a foundation upon which to build zAdditional work is required yArchitecture break-out yArchitecture working group