Dcmi architecture metadata entities and relationships
1 / 16

DCMI Architecture: Metadata Entities and Relationships - PowerPoint PPT Presentation

  • Uploaded on

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”

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'DCMI Architecture: Metadata Entities and Relationships' - haven

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Dcmi architecture metadata entities and relationships

DCMI Architecture:Metadata Entities and Relationships

Dublin Core 8 Workshop

National Library of Canada, Ottawa


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
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
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
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
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


  • Information Resource (Entity)

  • Agent Resource (Entity)

  • Relations between them (e.g. creator, publisher, editor, etc.)

  • Entities have descriptions

  • Agent

    • Associated characteristics (name, etc.)

  • Other Entities


  • 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

Dcmi architecture metadata entities and relationships












Landscapes and architecture
Landscapes and Architecture

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

  • Facilitate the design of Lego's

  • Support the notion of making complex statements out of simple sentences.

    • The development of “Lego Themes”

  • The design of common, simple principles

The benefits
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” analogy

  • Minor inconvenience for major benefits

Architectural considerations
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
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

Dcmi architecture metadata entities and relationships

<rdf:Description rdf:about = http://page.html>

<dc:title>XML Tutorial</dc:title>



<dca:name>Dan Brickley</dca:name>





“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”



“Dan Brickley”


Lego example rss and dc
Lego Example, RSS and DC

<rss:item rdf:about=“http://xml.com/pub/a/1234”>

<rss:title>A Story</rss:title>



<rss:topic rdf:resource=“http://dmoz.org/computers/operating_systems/macintosh”>

<rdf:value> Macintosh OS </rdf:value>




<rss:topic rdf:resource=“http://meerkat.oreillynet.com/category/55”>

<rdf:value> OS: Macintosh </rdf:value>




Where do we go from here
Where do we go from here…

  • Lego Architecture supports the initiative

  • We don’t have an entire solution

  • But we have a foundation upon which to build

  • Additional work is required

    • Architecture break-out

    • Architecture working group