Review of the DCMI Abstract Model

Transcription

1 Review of the DCMI Abstract Model Thomas Baker, DCMI Joint Mee>ng of the DCMI Architecture Forum and W3C Library Linked Data Incubator Group 22 October 2010 DRAFT SLIDES

2 Early 2000s DC straddling two mindsets New RDF graph mindset, reflected in: Dublin Core as an RDF vocabulary declared in a formal RDF schema Two parerns for DC in RDF/XML Tradi6onal IT record format mindset Element Set as slots in records Plethora of random concrete syntaxes HTML and XML very popular (e.g., OAI_DC format) Most implementa>ons made no reference to abstract syntax Interoperability among Dublin Core implementa>ons problema>c! Problem of mapping/profiling DC with IEEE LOM Not just about mapping elements Also about underlying model But RDF a hard sell Researchy, pie- in- the- sky Percep>on: Just another flavor of XML a (needlessly) complicated XML format

3 Role of DCAM mo>va>on: to build a bridge Transi>on from mindset of trees and record formats to mindset of linked graphs Harmoniza>on of na>ve DC model with RDF Today: quality and consistency of Linked Data? No>on of descrip6ve pa=erns reflec>ng exis>ng metadata prac>ce No>on of bounded records in support of provenance No>on of constraints on those graphs suppor>ng communi>es of prac>ce

4

5

6 Property URI Value URI Resource URI Property URI dcam:memberof Value URI rdf:value VES URI literal ^^SES URI Resource URI Property URI Property URI literal ^^SES URI

7 Property URI Value URI Resource URI Property URI dcam:memberof Value URI rdf:value VES URI literal ^^SES URI Resource URI Property URI Property URI literal ^^SES URI

8 DC- RDF Expressing Dublin Core metadata using the Resource Descrip>on Framework (RDF) Vocabulary Encoding Scheme URI Property URI Value URI dcam:memberof ex:examplesubjects hrp://example.org/123 dcterms:subject hrp://example.org/subject32 Value String rdf:value Biology rdf:value Value String Resource URI EA32 ^^ex:subjectencoding Value String Syntax Encoding Scheme URI hrp://dublincore.org/documents/dc- rdf/

9 A common abstract syntax for diverse concrete syntaxes

10 A common abstract syntax for diverse concrete syntaxes

11 To provide a common interface for interopera>ng across syntaxes interface implementa>on Applica>on A export DC abstract model encoding DC XML syntax transport Applica>on B import DC abstract model DC XML syntax interpreta>on

12 DCAM family of specifica>ons Model specifica6ons DCMI Abstract Model hrp://dublincore.org/documents/abstract- model/ Descrip>on Set Profiles: A constraint language for Dublin Core Applica>on Profiles hrp://dublincore.org/documents/dc- dsp/ Syntax expressions Guidelines for implemen>ng Dublin Core in XML (DC- XML) last updated not based on DCAM hrp://dublincore.org/documents/dc- xml/ Expressing Dublin Core Descrip>on Sets using XML (DC- DS- XML) hrp://dublincore.org/documents/dc- ds- xml/ Expressing Dublin Core metadata using HTML/XHTML meta and link elements (DC- HTML) hrp://dublincore.org/documents/dc- html/ Expressing Dublin Core metadata using the Resource Descrip>on Framework (RDF) hrp://dublincore.org/documents/dc- rdf/ Expressing Dublin Core metadata using the DC- Text format hrp://dublincore.org/documents/dc- text/ User Guidance Interoperability Levels for Dublin Core Metadata hrp://dublincore.org/documents/interoperability- levels/ DCMI Usage Board Criteria for the Review of Applica>on Profiles hrp://dublincore.org/documents/profile- review- criteria/ Singapore Framework for Dublin Core Applica>on Profiles hrp://dublincore.org/documents/singapore- framework/ Guidelines for Dublin Core Applica>on Profiles hrp://dublincore.org/usage/documents/profile- guidelines/

13 Descrip>on Set Profile Constraint Language Structural constraints on DCAM en>>es when used in records

14 Statement template: literal title Description Template: Book Property: dcterms:title Literal value Language SES A book: a literal >tle a creator, described separately A creator a literal name Statement template: creator Property: dcterms:creator Value URI Description reference: Creator Vocabulary Encoding Scheme Value string Language SES Statement template: literal name Description Template: Creator Property: foaf:name standalone:no Literal value Language SES Source: Mikael Nilsson

15 Singapore Framework for Dublin Core Applica>on Profiles Func>onal Require- ments built on Domain Model built on Descrip>on Set Profile built on Data Format Applica6on Profile uses uses built on built on Community Domain Models Metadata Vocabularies DCMI Abstract Model built on DCMI Syntax Guidelines Domain Standards built on built on Founda6on Standards RDFS (RDF Vocabulary Descrip>on Language) built on RDF Based on: hrp://dublincore.org/documents/singapore- framework/

16 Interoperability Levels for Dublin Core metadata Shared validatable constraints 4: Descrip>on Set Profile Interoperability Shared model for records Shared formal vocabularies and constraints in records 3: Descrip>on Set syntac>c interoperability Shared formal vocabularies in exchangeable records Shared formal- seman>c model 2: Seman>c interoperability Shared vocabularies based on formal seman>cs Shared 1: Informal (natural-language) interoperability definitions Shared vocabularies defined in natural language hrp://dublincore.org/documents/interoperability- levels/

17 Deployed base Shared constraints Shared records Shared formal- seman>c model Shared (natural-language) definitions

18 Future DCAM Scenarios 1. DCMI carries on developing DCAM as before incrementally improving the DCAM and Descrip>on Set Profile specifica>ons, with a work plan for further concrete syntaxes based on DCAM. 2. DCMI develops a DCAM 2 specifica6on simplified and berer aligned with RDF Variant 2a. The improved DCAM 2 specifica>on is taken as the new basis for structural constraints (DSP) and for con>nued work on concrete syntaxes Variant 2b. The improved DCAM 2 specifica>on is treated as a clarifica>on, for the benefit of the Dublin Core community, of how the DCAM abstract syntax relates to the RDF abstract syntax, to be deprecated over >me in favor of the larer. No new concrete syntaxes are undertaken. 3. DCMI deprecates DCAM a product of its >me and henceforth works on the basis of the RDF abstract syntax. 4. DCMI does nothing either to develop DCAM and DSP further or to change or clarify their exis>ng statuses. In effect, DCAM and DSP are frozen and de- emphasized, but with no par>cular explana>on.

19 Future DCAM Scenarios 1. DCMI carries on developing DCAM Incremental improvements to DCAM Structural constraints for applica>on profiles, as before, on basis of DSP Work plan for further concrete syntaxes based on DCAM (such as DC- DS- XML) Ques>ons: Is there a demonstrated interest? Who would edit the specs? How would review and tes>ng be managed?

20 Future DCAM Scenarios 2a. DCAM 2 as basis for new work DCMI would develop a DCAM 2 specifica>on simplified and berer aligned with RDF In Variant 2a, the improved DCAM 2 specifica>on would be taken as the new basis: for structural constraints of applica>on profiles (DSP) for a workplan to develop new and exis>ng concrete syntaxes Ques>ons: Is there a demonstrated interest in DCAM 2? Who would edit the specs? How would review and tes>ng be managed? What would be the impact of DCAM 2 on specifica>ons in the exis>ng DCAM family?

21 Future DCAM Scenarios 2b. DCAM 2 to clarify, then deprecate DCMI would develop DCAM 2 specifica>on Simplified and berer aligned with RDF In Variant 2b, different goal for DCAM 2 : Clarifica>on, for DC community, of how DCAM relates to RDF and Linked Data Transi>onal specifica>on, to be deprecated over >me in favor of RDF No new concrete syntaxes to be undertaken Ques>ons Is there clear interest in DCAM 2 (for purposes of clarifica>on and transi>on)? Who would edit DCAM 2? What should be done with the exis>ng DCAM family of specifica>ons?

22 Future DCAM Scenarios 3. Deprecate DCAM, embrace RDF DCMI deprecates DCAM A product of its >me Henceforth promote RDF abstract syntax Ques>ons Are there users of DCAM that would be nega>vely impacted? What should be done with the exis>ng DCAM family of specifica>ons? Status of each document Change of DCMI message What is an applica>on profile, if not based on DCAM (Singapore Framework, DSP )?

23 Future DCAM Scenarios 4. DCAM simply leo untouched DCMI does nothing No changes to DCAM or DSP or clarifica>on of their statuses. In effect, DCAM and DSP are frozen and de- emphasized, but with no par>cular explana>on. Ques>ons Does DCMI really stand behind con>nued recommenda>ons? What cost in reputa>on and credibility?

24 Issue: DCAM abstract syntax DCAM abstract syntax vs RDF abstract syntax Should DCAM dissolve into mainstream RDF? Are Descrip>ons and Descrip>on Sets expressible as Named Graphs? Significant differences between Vocabulary Encoding Schemes and SKOS Concept Schemes? DCAM- related modeling guidance Use of rdf:value (or skos:preflabel, rdfs:label, foaf:name, skos:nota>on, dcterms:>tle )?

25 Issue: Applica>on Profiles Does RDF need a no>on of Applica>on Profiles? What are the requirements? Do profiles need to express constraints? Represen>ng parerns of constraints at level of RDF graph Syntax parern checks Something like Descrip>on Set Profile constraint language? Like DSP approach, checking parerns in the graph rather than in the world? OWL applied with closed- world Assump>ons? Singapore Framework split : underlying vocabularies / data expressed using vocabularies At what level to express those constraints: Wired into specifica>on of underlying vocabulary? Expressed as parerns matched to the data?

26