Dcmi architecture metadata entities and relationships
This presentation is the property of its rightful owner.
Sponsored Links
1 / 16

DCMI Architecture: Metadata Entities and Relationships PowerPoint PPT Presentation


  • 57 Views
  • Uploaded on
  • Presentation posted in: General

DCMI Architecture: Metadata Entities and Relationships. Dublin Core 8 Workshop National Library of Canada, Ottawa 2000-10-04 Eric Miller, [email protected] Dan Brickley, [email protected] Rael Dornfest, [email protected] (Re)Discovery. DCMI – “Making it easier to find things using the web”

Download Presentation

DCMI Architecture: Metadata Entities and Relationships

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

2000-10-04

Eric Miller, [email protected]

Dan Brickley, [email protected]

Rael Dornfest, [email protected]


Re discovery

(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


Recognition

Recognition

  • 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


Architecture

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


Dcmi architecture metadata entities and relationships

Subject

Resource

Event

Resource

Agent

Resource

Information

Resource

Resource

Information

Resource


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>

<dc:creator>

<dca:Person>

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

<dca:email>[email protected]</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 [email protected]

title

creator

“XML Tutorial”

name

email

“Dan Brickley”

[email protected]


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

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


  • Login