1 / 39

An abstract model for DCMI metadata descriptions

An abstract model for DCMI metadata descriptions. DC Usage Board meeting at DC2003, Seattle September/October 2003. Andy Powell a.powell@ukoln.ac.uk UKOLN, University of Bath, UK http://www.ukoln.ac.uk/. UKOLN is supported by:. I am going to….

aviva
Download Presentation

An abstract model for DCMI metadata descriptions

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. An abstract model for DCMI metadata descriptions DC Usage Board meeting at DC2003, SeattleSeptember/October 2003 Andy Powell a.powell@ukoln.ac.uk UKOLN, University of Bath, UK http://www.ukoln.ac.uk/ UKOLN is supported by:

  2. I am going to… • assume people have read the current ‘Abstract Model’ working draft • propose a revised (more generic) abstract model • look at some of the issues that have been raised • encourage discussion of the revised model and the issues • consider what happens next with the abstract model document DC-2003 - Seattle, Sept/Oct 2003

  3. Major issues • why develop an abstract model? • what is ‘qualified DC’? whylimit to DCMI properties? • what is a ‘record’? • what is ‘simple DC’? why limit to DCMES • what is a ‘value’? • where does DCSV fit in? • relationship to ‘application profiles’? • relationship to RDF? • abstract model and dumb-down? DC-2003 - Seattle, Sept/Oct 2003

  4. Why? • non-syntax-based view of what constitutes a DC metadata description • need to understand what kinds of descriptions we are trying to encode • best done without reference to any particular syntax • allows us to compare and contrast the capabilities of different encodings • syntax X supports feature Y but syntax Z doesn’t • supports better mappings between syntaxes DC-2003 - Seattle, Sept/Oct 2003

  5. frankly my dear, I don’t give a DAM What is qualified DC? • general feeling that limiting abstract model for ‘qualified DC’ to DCMI properties is too limiting • real world applications typically go beyond this • therefore, need to re-model at more generic level • DCMI Abstract Model DC-2003 - Seattle, Sept/Oct 2003

  6. use of the word record may be a problem? DCMI abstract model • a description is made up of one or more properties and their associated values • each property is an attribute of the resource being described • properties may be repeated • a record is a set of descriptions about one or more related resources therefore… each description is about one, and only one, resource (the 1:1 principle) DC-2003 - Seattle, Sept/Oct 2003

  7. DCMI abstract model (2) • each value is a resource • each value may be denoted by a value string • each value string may have an associated encoding scheme • each encoding scheme is identified by an encoding scheme URI • each value string may have an associated language (e.g. en-GB) a value string is a ‘simple’, human-readable string DC-2003 - Seattle, Sept/Oct 2003

  8. DCMI abstract model (3) • each value may be identified by a value URI • each value may have an associated rich value (some marked-up text, an image, a video, some audio, etc. or some combination thereof) • each value may have some associated related metadata related metadata is a description of a related resource – e.g. metadata about the person who is the creator of a document… DC-2003 - Seattle, Sept/Oct 2003

  9. What is a record? • a record is a set of descriptions about one or more related resources, e.g. • a description of a resource and a description of its creator • a description of a resource, a rights statement about the resource and a description of the description • note: a description is about a single resource and is made up of one or more properties and their associated values DC-2003 - Seattle, Sept/Oct 2003

  10. What is a value? • a value is the physical or conceptual entity that is associated with a property when it is used to describe a resource • a person (physical) • an organisation (physical) • a subject (conceptual) • a country (physical) • a type (conceptual) • etc. • therefore, in the abstract model,a value is always a resource DC-2003 - Seattle, Sept/Oct 2003

  11. A value is always a resource • in the DCMI abstract model, a value is always a resource • the value resourcemay • be identified by a value URI • be denoted by a string value and/or a rich value • have some associated related metadata • …but the value is always a resource! • I think this has an impact on the RDF encodings?? DC-2003 - Seattle, Sept/Oct 2003

  12. But some problems… • some problems with wording of existing DCMES definitions… • CCP element values defined to be a ‘…resource…’ • relation, identifier and source defined to be a ‘…reference to a resource…’ • rights defined to be either a ‘…resource…’ or a ‘link to a service that provides a resource…’ • problem: too much of the model is embedded into the definition! DC-2003 - Seattle, Sept/Oct 2003

  13. What is qualified DC? • a ‘qualified DC record’ is … • any record that • conforms to the DCMI abstract model • contains a description that uses at least one DCMI term however, this means that it is probably not possible to define a single XML schema for qualified DC records – but can provide a template XML schema DC-2003 - Seattle, Sept/Oct 2003

  14. What is simple DC? • a ‘simple DC record’ is … • any record that • conforms to the DCMI abstract model • comprises only a single description • uses only properties taken from DCMES • makes no use of value URIs, encoding schemes, rich values or related metadata DC-2003 - Seattle, Sept/Oct 2003

  15. …or to put it differently • a simple DC record is made up of a single description • that description is made up of one or more properties and their associated values • each property is an attribute of the resource being described • each property must be one of the 15 DCMES elements • properties may be repeated • each value is denoted by a value string • each value string may have an associated language (e.g. en-GB) DC-2003 - Seattle, Sept/Oct 2003

  16. …or to put it differently • simple DC is an ‘application profile’ that only uses terms taken from the DCMES DC-2003 - Seattle, Sept/Oct 2003

  17. simple DC and value URIs • all values in simple DC are denoted using only a value string • the value string can be a URI… • …but there is nothing to formally indicate that the value string is a URI • simple DC software applications may choose to guess which value strings are URIs and which aren’t DC-2003 - Seattle, Sept/Oct 2003

  18. Simple DC and audience • why isn’t dcterms:audience included in ‘simple DC’? • because single namespace is simpler than multiple namespaces • dc:xxx and dcterms:xxx • because static definition is simpler than one that grows over time • audience + … + … • because, arguably, audience not part of the ‘core’ • the ‘t-shirt’ problem DC-2003 - Seattle, Sept/Oct 2003

  19. Abstract model and DCSV? • DCSV provides mechanism for encoding ‘markup’ in value string • thus DCSV runs slightly counter to the abstract model • DCSV better handled as ‘related metadata’ • e.g. Period provides related metadata about a conceptual ‘period in time’ • impact? XML enc. good – string enc. bad? • suggest no new proposals based on DSCV for the time being DC-2003 - Seattle, Sept/Oct 2003

  20. What is a DCAP? • a Dublin Core Application Profile (as currently defined) declares the properties and encoding schemes used to construct a description as used within a particular application • problems… • DCAPs don’t currently cover the whole abstract model • DCAPs define what a description is – but most ‘applications’ need defining at the record level DC-2003 - Seattle, Sept/Oct 2003

  21. RDF vs. abstract model • what is the relationship between RDF and the abstract model? • RDF provides richest encoding syntax currently • full encoding of all features of the model • but expect to see model fully implemented in XML as well • (expect HTML syntax to always be a partial implementation) DC-2003 - Seattle, Sept/Oct 2003

  22. Dumb-down • intelligent vs. dumb, element vs. value • element dumb-down (dumb) • ignore anything that isn’t [DCMES/an element] • element dumb-down (intelligent) • resolve sub-properties until you get to [DCMES/an element] • value dumb-down (dumb) • use value URI or value string as value string • value dumb-down (intelligent) • use knowledge of related metadata, or value string to create new value string • resolve sub-classes/broader terms DC-2003 - Seattle, Sept/Oct 2003

  23. sub-properties and classes • RDFS and human-readable declarations of DCMI terms refer to sub-properties and sub-classes • however, these don’t formally appear in the abstract model (expect as part of dumb-down) • where do these fit into the model? • I think they belong in the ‘grammatical principles’ document DC-2003 - Seattle, Sept/Oct 2003

  24. DC-2003 - Seattle, Sept/Oct 2003

  25. Example 1 – dc:creator <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <dc:creator> <rdf:Description> <rdf:value> Andy Powell </rdf:value> <my:email> a.powell@ukoln.ac.uk </my:email> </rdf:Description> </dc:creator> </rdf:Description> </rdf:RDF> Example RDF description using dc:creator… DC-2003 - Seattle, Sept/Oct 2003

  26. <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <dc:creator> <rdf:Description> <rdf:value> Andy Powell </rdf:value> <my:email> a.powell@ukoln.ac.uk </my:email> </rdf:Description> </dc:creator> </rdf:Description> </rdf:RDF> Example 1 – dc:creator Andy Powell… rdfs:label dc:creator Andy Po… my:name my:email a.powell@uko… a.powell@uko… my:affiliation UKOLN, Univ… …and the RDF model it represents. DC-2003 - Seattle, Sept/Oct 2003

  27. <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <dc:creator> <rdf:Description> <rdf:value> Andy Powell </rdf:value> <my:email> a.powell@ukoln.ac.uk </my:email> </rdf:Description> </dc:creator> </rdf:Description> </rdf:RDF> Example 1 – dc:creator relatedMetadata Andy Powell… rdfs:label dc:creator Andy Po… my:name my:email a.powell@uko… a.powell@uko… my:affiliation UKOLN, Univ… But… we don’t want to embed all this information into every instance metadata record do we? DC-2003 - Seattle, Sept/Oct 2003

  28. <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <dc:creator> <rdf:Description> <rdf:value> Andy Powell </rdf:value> </rdf:Description> </dc:creator> </rdf:Description> </rdf:RDF> <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <my:name> Andy Powell </my:name> <my:email> a.powell@ukoln.ac.uk </my:email> </rdf:Description> </rdf:RDF> Example 1 – dc:creator Andy Powell… rdfs:label dc:creator Andy Po… my:name my:email a.powell@uko… a.powell@uko… my:affiliation UKOLN, Univ… Need to separate part of the information out and store it in a single place – in this case in a directory service… DC-2003 - Seattle, Sept/Oct 2003

  29. <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <dc:creator> <rdf:Description> <rdf:value> Andy Powell </rdf:value> </rdf:Description> </dc:creator> </rdf:Description> </rdf:RDF> <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <my:name> Andy Powell </my:name> <my:email> a.powell@ukoln.ac.uk </my:email> </rdf:Description> </rdf:RDF> Example 1 – dc:creator Andy Powell… rdfs:label dc:creator Andy Po… valueURI valueURI my:name my:email a.powell@uko… a.powell@uko… my:affiliation UKOLN, Univ… To do this we need to assign a URI (the ‘valueURI’) to the anonymous ‘value’ node… DC-2003 - Seattle, Sept/Oct 2003

  30. <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <dc:creator> <rdf:Description> <rdf:value> Andy Powell </rdf:value> </rdf:Description> </dc:creator> </rdf:Description> </rdf:RDF> <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <my:name> Andy Powell </my:name> <my:email> a.powell@ukoln.ac.uk </my:email> </rdf:Description> </rdf:RDF> Example 1 – dc:creator relatedMetadataURI Andy Powell… rdfs:label dc:creator Andy Po… valueURI valueURI my:name my:email a.powell@uko… a.powell@uko… my:affiliation UKOLN, Univ… The document containing this information is itself an RDF resource (the ‘relatedMetadata’) and has a URI DC-2003 - Seattle, Sept/Oct 2003

  31. <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <dc:creator> <rdf:Description> <rdf:value> Andy Powell </rdf:value> <my:email> a.powell@ukoln.ac.uk </my:email> </rdf:Description> </dc:creator> </rdf:Description> </rdf:RDF> <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:my="http://purl.org…"> <rdf:Description> <dc:creator> <rdf:Description> <rdf:value> Andy Powell </rdf:value> <my:email> a.powell@ukoln.ac.uk </my:email> </rdf:Description> </dc:creator> </rdf:Description> </rdf:RDF> Example 1 – dc:creator relatedMetadataURI Andy Powell… rdfs:label dc:creator Andy Po… valueURI valueURI my:name my:email rdfs:seeAlso a.powell@uko… a.powell@uko… my:affiliation UKOLN, Univ… Use rdf:seeAlso to form linkage between description and relatedMetadata… DC-2003 - Seattle, Sept/Oct 2003

  32. Example 2 – dc:subject <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <rdf:Description> <dc:subject> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> <rdfs:label> Formate Dehydrogenase </rdfs:label> </dcterms:MESH> </dc:subject> </rdf:Description> </rdf:RDF> Example RDF description using dc:subject (taken from Qualified DC in RDF recommendation… DC-2003 - Seattle, Sept/Oct 2003

  33. Example 2 – dc:subject <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <rdf:Description> <dc:subject> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> <rdfs:label> Formate Dehydrogenase </rdfs:label> </dcterms:MESH> </dc:subject> </rdf:Description> </rdf:RDF> Formated… rdfs:label dc:subject rdfs:value D08.586… rdf:type rdf:type dcterms:MESH …and the RDF model it represents. DC-2003 - Seattle, Sept/Oct 2003

  34. Example 2 – dc:subject <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <rdf:Description> <dc:subject> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> <rdfs:label> Formate Dehydrogenase </rdfs:label> </dcterms:MESH> </dc:subject> </rdf:Description> </rdf:RDF> relatedMetadata Formated… rdfs:label dc:subject rdfs:value D08.586… rdf:type rdf:type dcterms:MESH But… we don’t want to embed all this information into every instance metadata record do we? DC-2003 - Seattle, Sept/Oct 2003

  35. Example 2 – dc:subject <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> <rdfs:label> Formate Dehydrogenase </rdfs:label> </dcterms:MESH> </rdf:RDF> <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <rdf:Description> <dc:subject> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> </dcterms:MESH> </dc:subject> </rdf:Description> </rdf:RDF> D08.586… Formated… rdfs:label dc:subject Formated… rdf:type rdf:type dcterms:MESH dcterms:MESH Need to separate part of the information out and store it in a single place – in this case with the terminology owner… DC-2003 - Seattle, Sept/Oct 2003

  36. Example 2 – dc:subject <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> <rdfs:label> Formate Dehydrogenase </rdfs:label> </dcterms:MESH> </rdf:RDF> <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <rdf:Description> <dc:subject> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> </dcterms:MESH> </dc:subject> </rdf:Description> </rdf:RDF> D08.586… Formated… rdfs:label dc:subject valueURI valueURI Formated… rdf:type rdf:type dcterms:MESH dcterms:MESH To do this we need to assign a URI (the ‘valueURI’) to the anonymous ‘value’ node… DC-2003 - Seattle, Sept/Oct 2003

  37. Example 2 – dc:subject <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> <rdfs:label> Formate Dehydrogenase </rdfs:label> </dcterms:MESH> </rdf:RDF> <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <rdf:Description> <dc:subject> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> </dcterms:MESH> </dc:subject> </rdf:Description> </rdf:RDF> relatedMetadataURI D08.586… Formated… rdfs:label dc:subject valueURI valueURI Formated… rdf:type rdf:type dcterms:MESH dcterms:MESH The document containing this information is itself an RDF resource (the ‘relatedMetadata’) and has a URI DC-2003 - Seattle, Sept/Oct 2003

  38. Example 2 – dc:subject <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> <rdfs:label> Formate Dehydrogenase </rdfs:label> </dcterms:MESH> </rdf:RDF> <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <rdf:Description> <dc:subject> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> </dcterms:MESH> </dc:subject> </rdf:Description> </rdf:RDF> relatedMetadataURI D08.586… Formated… rdfs:label dc:subject valueURI valueURI rdfs:seeAlso Formated… rdf:type rdf:type dcterms:MESH dcterms:MESH Use rdf:seeAlso to form linkage between description and relatedMetadata… DC-2003 - Seattle, Sept/Oct 2003

  39. Abstract DC model <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> <rdfs:label> Formate Dehydrogenase </rdfs:label> </dcterms:MESH> </rdf:RDF> <?xml version="1.0"?> <rdf:RDF xmlns:rdf=http://www…. xmlns:rdfs=http://www.w3.org/… xmlns:dc=http://purl.org/dc/… xmlns:dcterms="http://purl.org…"> <rdf:Description> <dc:subject> <dcterms:MESH> <rdf:value> D08.586.682.075.400 </rdf:value> </dcterms:MESH> </dc:subject> </rdf:Description> </rdf:RDF> resource resource relatedMetadataURI relatedMetadata D08.586… Formated… valueString valueString (valueStringLang) rdfs:label dc:subject valueURI property property valueURI valueURI valueURI rdfs:seeAlso Formated… rdf:type rdf:type dcterms:MESH dcterms:MESH In terms of abstract DC model we now have: resource, property, valueURI, valueString (and valueStringLang), encodingScheme, relatedMetadata encodingScheme DC-2003 - Seattle, Sept/Oct 2003

More Related