DCMI Architecture:Metadata Entities and Relationships

Dublin Core 8 Workshop

National Library of Canada, Ottawa

2000-10-04

Eric Miller, emiller@oclc.org

Dan Brickley, danbri@w3.org

Rael Dornfest, rael@oreilly.com

(Re)Discovery

DCMI – “Making it easier to find things using the web”

Examples: “Find me all the documents about the

subject woodworking” “Find me all the documents about the

subject woodworking created by any person with a name of Stu”

What we’ve learned…

Experience from dc-usage Identified pitfalls with describing people,

organizations, etc. in terms of documents that they create, publish, edit, etc.

Problems relate to discovery, description and reusability

Important to recognize that documents, people, organizations, etc. are independent (and as such have independent characteristics) but indeed are related.

Problematic Example

Dc.contributor.illustrator.organization.postcode Question: Is the postcode of the

organization that the illustrator works for a characteristic of the document?

Answer: no!But… we want/need to be able to

represent this for discovery (DCMI mission)

Grounded in Discovery

Finding documents requires describing documents

Finding documents requires describing people

Finding education-related documents requires describing additional characteristics of those people and documents…

Problems and Implications

Focus on describing information resources to the exclusion of other resources

Overloading the description of information resources

Results in Hard to partition working group activity Hard to effectively discover across metadata No coherent extensibility mechanism Interoperability across independent extensions

next to impossible

Recognition

Information Resource (Entity)Agent Resource (Entity)Relations between them (e.g.

creator, publisher, editor, etc.)Entities have descriptionsAgent

Associated characteristics (name, etc.)Other Entities

Architecture

History of difficulties DC-usage committee didn’t endorse any of the

proposed qualifiers for agents DC-usage couldn’t effectively move forward

without additional extensible, modular principles Architecture is required

Structure, qualification, versioning, multiple languages, domain-extensions: complexity!

Agent Working Group may be the first of many

Architecture has to work for all

InformationResource

AgentResource

InformationResource

Resource

Event Resource

SubjectResource

Landscapes and Architecture

Help with the conceptual view of DCMI activities and how things “fit together”

Facilitate the design of Lego'sSupport the notion of making complex

statements out of simple sentences. The development of “Lego Themes”

The design of common, simple principles

The benefits…

Of common, simple principles Enable all groups building legos to snap

together without a central process/authority structure

Strictly pragmatic requirements… we can’t afford weekly teleconferences of cross working group activities

Rael’s “Why palm pilots work” analogyMinor inconvenience for major

benefits

Architectural Considerations

Support the descriptive spectrum Simple literal value Syntactically including structured values Direct reference of resources

DDC, LAF, TGN, etc. Default values

Focus more on the “lego” interfaces among resources

Practical, pragmatic focus on discovery… back to basics… “Making it easier to find things using the web”

Scope and Complexity

How many types of entities and relationships are we talking about?

DCMI scope Ground questions in a context of the

original mission “Finding things using the web”

Finding and describing are bound together

“Dan Brickley”

“danbri@w3.org”

<rdf:Description rdf:about = http://page.html> <dc:title>XML Tutorial</dc:title> <dc:creator> <dca:Person> <dca:name>Dan Brickley</dca:name> <dca:email>danbri@w3.org</dca:email> </dca:Person> </dc:creator></rdf:Description>

“The resource has an identifier of http://page.html. 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 email address ‘danbri@w3.org’.”

“XML Tutorial”

title

creator

name

email

Lego Example, RSS and DC

<rss:item rdf:about=“http://xml.com/pub/a/1234”> <rss:title>A Story</rss:title> <rss:link>http://xml.com/2000/10/09/story.html</rss:link> <dc:subject> <rss:topic rdf:resource=“http://dmoz.org/computers/operating_systems/

macintosh”> <rdf:value> Macintosh OS </rdf:value> </rss:topic> </dc:subject> <dc:subject> <rss:topic rdf:resource=“http://meerkat.oreillynet.com/category/55”> <rdf:value> OS: Macintosh </rdf:value> </rss:topic> </dc:subject></rss:item>

Where do we go from here…

Lego Architecture supports the initiative

We don’t have an entire solutionBut we have a foundation upon which

to build Additional work is required

Architecture break-out Architecture working group