1 / 16

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

haven
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. (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”

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

  4. 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)

  5. 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…

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

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

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

  9. Subject Resource Event Resource Agent Resource Information Resource Resource Information Resource

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

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

  12. 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”

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

  14. <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’.” title creator “XML Tutorial” name email “Dan Brickley” “danbri@w3.org”

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

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

More Related