• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
DC Architecture WG Meeting - DC-2006, Mexico
 

DC Architecture WG Meeting - DC-2006, Mexico

on

  • 5,346 views

Slides prepared for the DC Architecture Working Group meeting at the DC-2006 conference held in Manzanillo, Mexico in October 2006. (Note that not all these slides were used during the meeting - but ...

Slides prepared for the DC Architecture Working Group meeting at the DC-2006 conference held in Manzanillo, Mexico in October 2006. (Note that not all these slides were used during the meeting - but they were ready to be used if necessary!)

Statistics

Views

Total Views
5,346
Views on SlideShare
5,342
Embed Views
4

Actions

Likes
1
Downloads
0
Comments
0

2 Embeds 4

http://www.techgig.com 3
http://my.opera.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

DC Architecture WG Meeting - DC-2006, Mexico DC Architecture WG Meeting - DC-2006, Mexico Presentation Transcript

  • DC Architecture WG meeting DC-2006, Mexico Tuesday Oct 3 16.30 - 18.30
  • Agenda
    • introductory session
      • where we’ve been and where we are going
      • but not a tutorial
    • 5 minute break
    • advanced session
      • meeting of the working group
      • detailed discussion about DC Abstract Model, DC-RDF, DC-XML
  • Aims
    • knowledge sharing
    • discussion of issues
      • do the proposed revisions to abstract model address concerns that have been raised
      • relationship between DCAM and SKOS
      • consider nature of our DC-XML guidelines
    • intention is to inform the next iteration of the working drafts
  • Important
    • this meeting is intended to be informal and interactive
    • please ask questions if you don’t understand
    • please raise issues if you disagree
    • introduce yourself before speaking
  • Session leaders
    • Andy Powell
      • chair of DC Architecture / DC Abstract Model
    • Pete Johnston
      • author of DC-XML / DC Abstract Model
    • Mikael Nilsson
      • author of DC-RDF / DC Abstract Model
    • Tom Baker
      • chair of DC Usage Board
  • Agenda
    • review of progress during the year
      • summary of DCMI Abstract Model, DC-RDF and DC-XML
      • note about related Usage Board activities
    • DC-Architecture and Usage Board roadmap for next year
  • Progress during 2006
    • DC-XML issued as working draft
    • DC-RDF issued as working draft
    • comment periods for both undertaken
    • draft of revision to DCMI Abstract Model prepared – based on issues raised by comment period and other comments
    • also… draft update to DCMI namespace policy waiting to go out for comment
  • Progress - DC-XML
    • Guidelines for implementing Dublin Core in XML
      • DCMI Recommendation, April 2003
    • pre-dates development of DCAM
    • uses two earlier, simpler “abstract models”
      • “ Simple DC” model can be mapped to DCAM description model
      • “ Qualified” model can not be mapped to DCAM description model
  • DC-XML (2)
    • no DCMI guidance for representing DC description sets using XML
    • March 2006: DCMI contract to produce revised XML format
    • working draft issued for comment
    • comments currently being addressed
  • Progress DC-RDF
  • DC-Architecture WG DC-RDF updates
      • Mikael Nilsson
      • [email_address]
      • The Knowledge Management Research Group
      • Royal Institute of Technology, Stockholm
      • http://kmr.nada.kth.se
  • New DC-RDF Working Draft!
    • Successful public comment in June, 2006
    • Will be revised and discussed more
    • If accepted, will replace
      • Expressing Simple Dublin Core in RDF/XML , a DCMI Recommendation from July 2002;
      • Expressing Qualified Dublin Core in RDF / XML , a DCMI Proposed Recommendation from May 2002.
  • Main features
    • a unified specification for Dublin Core in RDF
    • full support for the DCMI Abstract Model
    • good integration with other RDF metadata
    • supports domains and ranges
      • <http://www.example.com> dcterms:creator &quot;John Smith&quot; – no longer valid!
    • much more regular – many complicated options deprecated
  •  
  • Progress - Abstract Model
    • DCMI Abstract Model has generated comments from:
      • DCMI Usage Board
      • DCMI Working Groups, particularly WGs developing DCAPs
      • implementers of DCAPs
      • developers/implementers of related specs (e.g. SKOS)
      • researchers
      • implementers of metadata registries
      • authors/editors of “encoding guidelines” specifications
  • Abstract Model (2)
    • use of DCAM has:
      • highlighted omissions, ambiguities, redundancies, errors
      • created better understanding of what is required
      • emphasised value of an abstract model!
    • all of which has fed into process for producing draft revised abstract model (see Wiki)
      • http://dublincore.org/architecturewiki/AMDraftUpdate
  • Progress - Namespace Policy
    • no real progress!
    • revised and discussed at DC-Arch meeting last year
    • pretty much static since then
    • may be some minor issues around replicating terms from DC namespace to DCTERMS namespace
    • need to move to recommendation
  • Usage Board activities
    • in parallel the DC Usage Board has been
    • working on assigning domains and ranges to DCTERMS
      • in order to make some of the property semantics explicit in machine-readable form
    • clarifying whether each of the current encoding schemes is a ‘syntax encoding scheme’ or a ‘vocabulary encoding scheme’
  • What is a domain?
    • Each property may be related to one or more classes by a has domain relationship. Where it is stated that a property has such a relationship with a class and a described resource is related to a value by that property , it follows that the described resource is an instance of that class .
    • e.g. domain of dc:creator is Resource
  • What is a range?
    • Each property may be related to one or more classes by a has range relationship. Where it is stated that a property has such a relationship with a class and a described resource is related to a value by that property , it follows that the value is an instance of that class .
    • e.g. range of dc:creator is Agent
  • Liaison with Swoogle
    • before assigning domains and ranges we needed to understand how DC properties are currently used in RDF
    • obtained statistics from Swoogle
      • e.g. showed that dc:creator mainly used with range of rdfs:Literal
    • as a result, our current plan is to copy the 15 DCMES properties into the DCTERMS namespace and assign domains and ranges to them there
  • Strategic priorities - 2007
    • refine the Abstract Model
    • finish updates to DC-RDF and DC-XML and align model in DC-HTML guidelines
    • banish semantic fuzziness by assigning domains and ranges to DCTERMS
    • agree how we model application profiles
  • DC Arch and Usage Board Roadmap for next year Tom
  • Usage Board support for DC Architecture developments
    • September 2006 – Manzanillo
      • DC-Architecture
        • DCAM update
        • Revised DC-RDF, DC-XML, DC-Text
      • Usage Board
        • DCMES changes – finalization
        • Range vocabulary – review definitions, proposed assignments
        • Existing terms as syntax or vocabulary encoding schemes
  • Usage Board and DC-Architecture: Joint Work Plan
    • October through December 2006
      • DC-Architecture
        • Prepare DCAM, DC-Text, DC-XML, DC-RDF, DCMI Namespace Policy for public comment
          • Extend DCAM with Vocabulary Model and Profile Model
        • RDF schemas with ranges for purposes of testing
      • UB
        • Prepare range vocabulary for public comment
  • Usage Board and DC-Architecture: Joint Work Plan
    • January to March 2007 – DCMI
      • Public comment period for DCAM, etc
        • Resulting in DCMI Recommendations
      • User-oriented “how-to” documentation for making profiles and vocabularies
    • April 2007 – Usage Board
      • Approve vocabulary range as new DCMI terms
      • Approve assignment of ranges to existing terms
  • 5 minute break
  • Agenda
    • Abstract Model
    • DC-RDF
    • DC-XML
  • DCMI Abstract Model Pete
  • DCMI Abstract Model: issues and proposed changes DCMI Architecture Working Group DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
  • Background
    • DCMI Abstract Model
      • DCMI Recommendation March 2005
    • DCAM describes
      • Components and constructs that make up an information structure (“DC description set”)
      • How that information structure is to be interpreted
    • DCAM does not describe how to represent DC description set in concrete form
  • DCAM Description Model
    • a description set is made up of one or more descriptions
    • a description is made up of
      • zero or one resource URI and
      • one or more statements
    • a statement is made up of
      • exactly one property URI and
      • zero or one reference to a value in the form of a value URI
      • zero or more representations of a value, each in the form of a value representation
      • zero or one vocabulary encoding scheme URI
    • a value representation is either
      • a value string or
      • a rich representation
    • a value string may have an associated value string language
    • a value string may have an associated syntax encoding scheme URI
    • a value may be the subject of a related description
  • Resource URI Property URI Rich representation Property URI Value URI Vocab Enc Scheme URI Property URI Value string Syntax Enc Scheme URI Value string Syntax Enc Scheme URI Resource URI Property URI Rich representation Property URI Value URI Vocab Enc Scheme URI Property URI Value string Syntax Enc Scheme URI Statement Description Description Set
  • DCMI Abstract Model in use
    • Use of DCAM has generated comments from e.g.
      • DCMI Usage Board
      • DCMI Working Groups, particularly WGs developing DCAPs
      • Implementers of DCAPs
      • Developers/implementers of related specs (e.g. SKOS)
      • Researchers
      • Implementers of metadata registries
      • Authors/editors of “encoding guidelines” specifications
      • (and others!)
    • Use of DCAM has
      • highlighted omissions, ambiguities, redundancies, errors
      • created better understanding of what is required
      • emphasised value of an abstract model!
  • Proposed changes
    • Issues collated in
      • http://dublincore.org/architecturewiki/AMIssues
    • Some editorial/presentational change
    • Remove some historical information
    • Clarify existing concepts/constructs
    • Extend to include new concepts/constructs
  • Editorial/presentational change
    • Purpose of DCAM
      • (Current) “ The primary purpose of this document is to provide a reference model against which particular DC encoding guidelines can be compared. To function well, a reference model needs to be independent of any particular encoding syntax. ”
      • Doesn’t reflect role of DCAM in defining what DC metadata is, the nature of the components used, and how they are interpreted
      • Also DCAM should be starting point for “encoding guidelines”
      • (Proposed) “The primary purpose of this document is to specify the components and constructs used in Dublin Core metadata. It defines the nature of the components used and describes how those components are combined to create information structures. It provides a reference model which is independent of any particular encoding syntax.”
  • Editorial/presentational change
    • Vocabulary Model
      • Description of types of terms and types of relationships that exist between terms
      • Based on RDF Schema
      • Currently embedded in “Resource Model”/Figure 1
      • Useful to make more explicit
      • Also some extensions required (more later)
  • Remove some historical information
    • Appendices contain discussion of specs based on earlier/different “abstract models”
      • e.g. appendices on encoding guidelines in 2003
      • attempts to retrofit DCAM confusing (inaccurate?)
      • redundant once DCMI adopts encoding guidelines based on DCAM
    • Confused terminology in discussion of “structured values”
      • addressed in revisions to DCSV, Box, Period, Point (2006)
    • Useful for context of DCAM in 2003, but should not be part of document
  • Clarify existing concepts/constructs
    • Phrasing of some definitions is inconsistent with usage in text e.g.
      • Term
        • (Current) The generic name for a property (i.e. element or element refinement ), vocabulary encoding scheme , syntax encoding scheme or concept taken from a controlled vocabulary (concept space).
        • (Proposed) A property (i.e. element or element refinement ), vocabulary encoding scheme , s yntax encoding scheme or concept taken from a controlled vocabulary (concept space).
  • Clarify existing concepts/constructs
    • Sub-property/Sub-class
      • Currently modelled as distinct classes
      • Should be represented in Vocabulary Model as relationships between properties, classes
      • i.e. same concepts as in RDF Schema
      • Also provide definitions in glossary
  • Clarify existing concepts/constructs
    • “ Description Set”
      • Need to emphasise that “description set” is primary “abstract information structure”
      • Proposal: Add “ A description set is a set of one or more descriptions” to textual description of description model
    • “ Related description”
      • Need to emphasise that a “related description” is just a description
      • Proposal: use “description of value” etc
    • “ Resource”/”Resource URI” and “Value”/”Value URI”
      • A value is a resource, so sometimes use of “resource” seems ambiguous
      • Proposal: use “described resource” to refer to subject of description
  • Clarify existing concepts/constructs
    • Value strings, language tags & syntax encoding schemes
      • (Currently) allow value string to be associated with both a language tag and a syntax encoding scheme (datatype)
      • Proposal: permit value string to be associated with either language tag or syntax encoding scheme, or neither, but not both
    • “ Empty statements”
      • (Currently) allow a statement with no value URI or value representation and no (“related”) description of value
      • Proposal: specify that value URI or value representation must be provided unless value is subject of separate description
  • Clarify existing concepts/constructs
    • Syntax encoding schemes
      • (Currently) A syntax encoding scheme indicates that the value string is formatted in accordance with a formal notation, such as &quot;2000-01-01&quot; as the standard expression of a date.
      • SES includes a “contract” for interpretation of literal
      • But “formatted” too narrow
        • ISO 3166, xsd:Boolean, xsd:int
      • Doesn’t capture notion that SES indicates that literal “stands for” something else
      • Proposal: A syntax encoding scheme is a set of strings that is associated with a set of rules which describe a mapping between that set of strings and a set of resources. The mapping rules may be based on a description of how the string is structured (e.g. DCMI Box) or they may be based on a simple enumeration of all the strings and the corresponding resource (e.g. ISO 3166).
  • Extend to include new concepts/constructs
    • Range/domain
      • DCMI plans to make range/domain assertions for DCMI-owned properties
        • Making explicit to software what is implicit in human-readable descriptions
      • Should be added to Vocabulary Model as relationships between properties, classes
      • i.e. same concepts as in RDF Schema
      • Also provide definitions in glossary
  • Extend to include new concepts/constructs
    • Vocabulary Encoding Scheme v Class of Value
      • (currently) VES = class of Value
      • Conflict with existing DCMI use of concept e.g.
        • class of LCSH terms considered a VES
        • class of collections or class of persons not considered VES
      • Also integration with SKOS
        • relation between Concept and ConceptScheme is skos:inScheme not rdf:type (instance-of)
        • so difficult to use same resource as skos:ConceptScheme and as VES
      • What distinguishes a VES from a Class?
      • Proposal: VES as enumerable set of resources
      • Proposal: Add Value Class URI to description model (in addition to VES URI)
  • Other issues not yet discussed
    • Rich Representations & MIME types
      • Should DCAM description model specify that rich representation should be associated with MIME type?
    • “ Conformance to DCAM”
  • DCMI Abstract Model: issues and proposed changes DCMI Architecture Working Group DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
  • Encoding guidelines DC-RDF Mikael
  • Encoding guidelines DC-XML Pete
  • Expressing DC metadata in XML: a status report to DCMI Architecture WG DCMI Architecture Working Group DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
  • Expressing DC metadata in XML
    • Background
    • DC-XML 2006-05-29
      • public comment version
    • DC-XML 2006-07-04
      • draft to DC Arch WG
      • verbosity, human readability, “hard to explain”
      • no “term-level” validation with W3C XML Schema
    • DC-XML-Full 2006-09-18
      • draft to DC Arch WG
      • extension to DC-XML 2006-07-04
    • DC-XML-Min 2006-09-18
      • draft to DC Arch WG
      • supports subset of DCAM description model
    • Moving forward?
  • Background
    • DCMI Abstract Model
      • DCMI Recommendation March 2005
    • DCAM describes
      • Components and constructs that make up an information structure (“DC description set”)
      • How that information structure is to be interpreted
    • DCAM does not describe how to represent DC description set in concrete form
  • Resource URI Property URI Rich representation Property URI Value URI Vocab Enc Scheme URI Property URI Value string Syntax Enc Scheme URI Value string Syntax Enc Scheme URI Resource URI Property URI Rich representation Property URI Value URI Vocab Enc Scheme URI Property URI Value string Syntax Enc Scheme URI Statement Description Description Set
  • Background
    • Guidelines for implementing Dublin Core in XML
      • DCMI Recommendation, April 2003
      • Pre-dates development of DCAM
      • Uses two earlier, simpler “DC abstract models”
      • “ Simple DC metadata record” model can be mapped to DCAM description model
      • “ Qualified DC metadata record” model can not be mapped to DCAM description model
    • No DCMI guidance for representing DC description sets using XML
    • March 2006: DCMI contract to produce revised XML format
  • Design Principles
    • Should support all features of DCAM description model
    • Not required to express DCAM vocabulary model (subproperty, subclass etc)
    • Should be easily usable with XPath, XPointer, XQuery etc
    • Should not be dependent on features of one XML Schema language
    • Should be amenable to description using W3C XML Schema
    • But not required that all constraints of a DCAP captured in W3C XML Schema
  • <dcx:descriptionSet> <dcx:description dcx:resourceURI=&quot;http://dublincore.org/pages/home&quot;> <dc:title> <dcx:valueString>DCMI Home Page</dcx:valueString> </dc:title> <dc:subject dcx:vocabEncSchemeURI=&quot;http://purl.org/dc/terms/LCSH&quot;> <dcx:valueString>Metadata</dcx:valueString> </dc:subject> <dcterms:isPartOf dcx:valueURI=&quot;http://dublincore.org/site&quot; /> <dc:publisher dcx:descriptionRef=&quot;dcmi&quot; /> </dcx:description> <dcx:description dcx:descriptionId=&quot;dcmi&quot;> <my:name> <dcx:valueString>Dublin Core Metadata Initiative</dcx:valueString> </my:name> </dcx:description> </dcx:descriptionSet> DC-XML 2006-05-29
  • <dcx:descriptionSet> <dcx:description dcx:resourceURI=&quot;http://dublincore.org/pages/home&quot;> <dc:title> <dcx:valueString>DCMI Home Page</dcx:valueString> </dc:title> <dc:subject dcx:vocabEncSchemeURI=&quot;http://purl.org/dc/terms/LCSH&quot;> <dcx:valueString>Metadata</dcx:valueString> </dc:subject> <dcterms:isPartOf dcx:valueURI=&quot;http://dublincore.org/site&quot; /> <dc:publisher dcx:descriptionRef=&quot;dcmi&quot; /> </dcx:description> <dcx:description dcx:descriptionId=&quot;dcmi&quot;> <my:name> <dcx:valueString>Dublin Core Metadata Initiative</dcx:valueString> </my:name> </dcx:description> </dcx:descriptionSet> DC-XML 2006-05-29 Property URI as XML QName (as XML element name) VES URI as XML attribute value Resource URI, Value URI as XML attribute values
  • <dcx:descriptionSet> <dcx:description dcx:resourceURI=&quot;http://dublincore.org/pages/home&quot;> <dc:title> <dcx:valueString>DCMI Home Page</dcx:valueString> </dc:title> <dc:subject dcx:vocabEncSchemeQName=&quot;dcterms:LCSH&quot; > <dcx:valueString>Metadata</dcx:valueString> </dc:subject> <dcterms:isPartOf dcx:valueURI=&quot;http://dublincore.org/site&quot; /> <dc:publisher dcx:descriptionRef=&quot;dcmi&quot; /> </dcx:description> <dcx:description dcx:descriptionId=&quot;dcmi&quot;> <my:name> <dcx:valueString>Dublin Core Metadata Initiative</dcx:valueString> </my:name> </dcx:description> </dcx:descriptionSet> DC-XML 2006-05-29 VES URI as XML QName (as XML attribute value) (“Related”) description of value linked by id/idref
  • Main comments on DC-XML 2006-05-29
    • XML elements v XML attributes
    • Variation in representation of URIs
      • Resource URI, Value URI as URI
      • VES URI, SES URI as URI or as QName
      • Property URI as QName
    • XML QNames in XML attribute values
    • DCAM issues
      • Rich representations and MIME types
  • <dcx:descriptionSet> <dcx:description dcx:resourceURI=&quot;http://dublincore.org/pages/home&quot;> <dcx:statement dcx:propertyURI=&quot;http://purl.org/dc/elements/1.1/title&quot;> <dcx:valueString>DCMI Home Page</dcx:valueString> </dcx:statement> <dcx:statement dcx:propertyURI=&quot;http://purl.org/dc/elements/1.1/subject&quot; dcx:vocabEncSchemeURI=&quot;http://purl.org/dc/terms/LCSH&quot;> <dcx:valueString>Metadata</dcx:valueString> </dcx:statement> <dcx:statement dcx:propertyURI=&quot;http://purl.org/dc/terms/isPartOf&quot; dcx:valueURI=&quot;http://dublincore.org/site&quot; /> <dcx:statement dcx:propertyURI=&quot;http://purl.org/dc/elements/1.1/publisher&quot; dcx:descriptionRef=&quot;dcmi&quot; /> </dcx:description> <dcx:description dcx:descriptionId=&quot;dcmi&quot;> <dcx:statement dcx:propertyURI=&quot;http://my.example.org/terms/name&quot;> <dcx:valueString>Dublin Core Metadata Initiative</dcx:valueString> </dcx:statement> </dcx:description> </dcx:descriptionSet> DC-XML 2006-07-04
  • <dcx:descriptionSet> <dcx:description dcx:resourceURI=&quot;http://dublincore.org/pages/home&quot;> <dcx:statement dcx:propertyURI=&quot;http://purl.org/dc/elements/1.1/title&quot;> <dcx:valueString>DCMI Home Page</dcx:valueString> </dcx:statement> <dcx:statement dcx:propertyURI=&quot;http://purl.org/dc/elements/1.1/subject&quot; dcx:vocabEncSchemeURI=&quot;http://purl.org/dc/terms/LCSH&quot;> <dcx:valueString>Metadata</dcx:valueString> </dcx:statement> <dcx:statement dcx:propertyURI=&quot;http://purl.org/dc/terms/isPartOf&quot; dcx:valueURI=&quot;http://dublincore.org/site&quot; /> <dcx:statement dcx:propertyURI=&quot;http://purl.org/dc/elements/1.1/publisher&quot; dcx:descriptionRef=&quot;dcmi&quot; /> </dcx:description> <dcx:description dcx:descriptionId=&quot;dcmi&quot;> <dcx:statement dcx:propertyURI=&quot;http://my.example.org/terms/name&quot;> <dcx:valueString>Dublin Core Metadata Initiative</dcx:valueString> </dcx:statement> </dcx:description> </dcx:descriptionSet> DC-XML 2006-07-04 Property URI as XML attribute value Statement Element name = dcx:statement
  • <dcx:descriptionSet> <dcx:namespaceDeclaration dcx:prefix=&quot;dc&quot; dcx:namespaceURI=&quot;http://purl.org/dc/elements/1.1/&quot; /> <dcx:namespaceDeclaration dcx:prefix=&quot;dcterms&quot; dcx:namespaceURI=&quot;http://purl.org/dc/terms/&quot; /> <dcx:namespaceDeclaration dcx:prefix=“page&quot; dcx:namespaceURI=&quot;http://dublincore.org/pages/&quot; /> <dcx:description dcx:resourceQualName=&quot;page-home&quot;> <dcx:statement dcx:propertyQualName=“dc-title&quot;> <dcx:valueString>DCMI Home Page</dcx:valueString> </dcx:statement> <dcx:statement dcx:propertyQualName=“dc-subject&quot; dcx:vocabEncSchemeQualName=&quot;dcterms-LCSH&quot;> <dcx:valueString>Metadata</dcx:valueString> </dcx:statement> <dcx:statement dcx:propertyQualName=&quot;dcterms-isPartOf&quot; dcx:valueURI=&quot;http://dublincore.org/site&quot; /> </dcx:description> </dcx:descriptionSet> DC-XML 2006-07-04 Qualified Name not based on XML QNames
  • Main comments on DC-XML 2006-07-04
    • XML element names reflect names of DCAM constructs
      • cf TriX for RDF
    • Verbose
    • Limits validation that can be performed using W3C XML Schema? (e.g. “property-level validation”)
    • Difficult to explain to human reader/writer?
      • Q: “Why can’t I just use this?”
        • <dcx:descriptionSet>
        • <dcx:description>
        • <dc:subject>Metadata</dc:subject>
        • </dcx:description>
        • </dcx:descriptionSet>
      • A: (Because XML element represents statement and DCAM supports multiple value strings per statement)
    • But if we agree on a subset of the DCAM model….
  • DCAM Description Model (Subset)
    • a description set is made up of one or more descriptions
    • a description is made up of
      • zero or one resource URI and
      • one or more statements
    • a statement is made up of
      • exactly one property URI and
      • zero or one reference to a value in the form of a value URI
      • zero or one representation of a value in the form of a value string
      • zero or one vocabulary encoding scheme URI
      • zero or one value class URI
    • a value string may be associated with either a value string language or a syntax encoding scheme URI
    • a value may be the described resource of another description in the description set
  • <dcx:descriptionSet> <dcx:description dcx:resourceURI=&quot;http://dublincore.org/pages/home&quot;> <dc:title>DCMI Home Page</dc:title> <dc:subject dcx:vocabEncSchemeURI=&quot;http://purl.org/dc/terms/LCSH&quot;> Metadata </dc:subject> <dcterms:isPartOf dcx:valueURI=&quot;http://dublincore.org/site&quot; /> <dc:publisher dcx:descriptionRef=&quot;dcmi&quot; /> </dcx:description> <dcx:description dcx:descriptionId=&quot;dcmi&quot;> <my:name>Dublin Core Metadata Initiative</my:name> </dcx:description> </dcx:descriptionSet> DC-XML-Min 2006-09-18
  • Main comments on DC-XML-Min 2006-09-18
    • Addresses problems of verbosity
    • Could DC-XML-Min be made a (W3C XML-Schema-friendly) profile of RDF/XML?
      • dcxm:description -> rdf:Description
      • @dcxm:resourceURI -> @rdf:about
      • @dcxm:valueURI -> @rdf:resource
      • @dcxm:vocabEncSchemeURI -> @dcrdf:inScheme or @dcrdf:isMemberOf (or whatever we decide the property for that relationship is)
      • @dcxm:valueClassURI -> @rdf:type
      • @dcxm:descriptionId -> @rdf:nodeID
      • @dcxm:descriptionRef -> @rdf:nodeID
  • <dcx:descriptionSet> <dcx:description rdf:about=&quot;http://dublincore.org/pages/home&quot;> <dc:title>DCMI Home Page</dc:title> <dc:subject dcrdf:isMemberOf=&quot;http://purl.org/dc/terms/LCSH&quot;> Metadata </dc:subject> <dcterms:isPartOf rdf:resource=&quot;http://dublincore.org/site&quot; /> <dc:publisher rdf:nodeID=&quot;dcmi&quot; /> </dcx:description> <dcx:description rdf:nodeID =&quot;dcmi&quot;> <my:name>Dublin Core Metadata Initiative</my:name> </dcx:description> </dcx:descriptionSet>
  • Main comments on DC-XML-Min 2006-09-18
    • However… need blank nodes and typed literals
    Property Element with @ rdf:parseType=“Resource” and child Property Element: <rdf:Description rdf:about=&quot;http://dublincore.org/pages/home&quot;> <dc:subject rdf:parseType=&quot;Resource&quot;> <dcrdf:valueString>History</dcrdf:valueString> </dc:subject> </rdf:Description> Node Elements and rdf:nodeID: <rdf:Description rdf:about=&quot;http://dublincore.org/pages/home&quot;> <dc:subject rdf:nodeID=&quot;history&quot; /> </rdf:Description> <rdf:Description rdf:nodeID=&quot;history&quot;> <dcrdf:valueString>History</dcrdf:valueString> </rdf:Description>
  • Moving forward?
    • DC-XML-Full 2006-09-18
      • Supports full DCAM description model (incl. Value Class)
      • Uses dcx:statement for Statement Element name
      • All URIs as attribute values
      • No XML QNames in XML content (but DC Qualified Name mechanism needs testing)
    • DC-XML-Min 2006-09-18
      • Supports subset of DCAM description model
      • Property URIs as XML QNames (XML element names); other URIs as attribute values
      • Probably not a profile of RDF/XML
      • but we do have GRDDL!
    • Does DCMI need both?
    • Or is DC-XML-Min sufficient?
  • Expressing DC metadata in XML: a status report to DCMI Architecture WG DCMI Architecture Working Group DC-2006: Metadata for Knowledge & Learning, Manzanillo, Mexico
  • Application profile model ?
  • Workplan for next year Andy