160 likes | 259 Views
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”
E N D
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 descriptions • Agent • 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
Subject Resource Event Resource Agent Resource Information Resource Resource Information Resource
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… • 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 • 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
<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”
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 solution • But we have a foundation upon which to build • Additional work is required • Architecture break-out • Architecture working group