DCMI Architecture Forum telecon - Thursday, 2010-10-07, 1400 Amsterdam time
0500 Seattle - 0800 New York - 1400 Amsterdam
http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=7&year=2010&hour=12&min=00&sec=0&p1=0
Dial-in Number: +1-218-936-4141
Participant Access Code: 334034
Expected: TomB, PeteJ, StuartS, AndyP, AntoineI, AnaB,
EmmanuelleB, MikaelN, DanBri (with space on call for up to
five more)
----------------------------------------------------------------------
Meeting in Pittsburgh
-- Agenda
http://www.w3.org/2001/sw/wiki/JointMeeting2010
http://www.asis.org/Conferences/DC2010/program-sessions.html#jointmeeting
-- Preparation on mailing lists
http://www.jiscmail.ac.uk/lists/dc-architecture.html
http://lists.w3.org/Archives/Public/public-lld/ - http://tinyurl.com/24jsdtv
-- Participation
Remote participation via Zakim
Registration at DC-2010 is required for on-site participation
----------------------------------------------------------------------
Review of the DCMI Abstract Model
-- Under development by Tom and Pete at:
http://dublincore.org/architecturewiki/DcamInContext
-- Look for final version on Friday, 15 October
-- Tom proposes to split existing DcamInContext document into:
DcamInContext
keep (and expand) historical context
move scenarios for further DCAM development into...
DcamReview
Scenarios outlined below.
----------------------------------------------------------------------
Scenarios for future development of DCAM
1. DCMI carries on developing DCAM
Incremental improvements to DCAM
Structural constraints for application profiles, as before, on basis of DSP
Work plan for further concrete syntaxes based on DCAM (such as DC-DS-XML)
Questions:
-- Is there a demonstrated interest?
-- Who would edit the specs?
-- How would review and testing be managed?
2a. "DCAM 2" as basis for new work
DCMI would develop a "DCAM 2" specification -- simplified and
better aligned with RDF
In Variant 2a, the improved DCAM 2 specification would be taken as
the new basis:
-- for structural constraints of application profiles (DSP)
-- for a workplan to develop new and existing concrete syntaxes
Questions:
-- Is there a demonstrated interest in "DCAM 2"?
-- Who would edit the specs?
-- How would review and testing be managed?
-- What would be the impact of "DCAM 2" on specifications in the existing "DCAM family"?
2b. "DCAM 2" for clarification then deprecation
DCMI would develop a "DCAM 2" specification -- simplified and
better aligned with RDF
In Variant 2b, different goal for "DCAM 2":
-- Clarification, for DC community, of how DCAM relates to RDF and Linked Data
-- Transitional specification, to be deprecated over time in favor of RDF
-- No new concrete syntaxes to be undertaken
Questions
-- Is there clear interest in "DCAM 2" (for purposes of clarification and transition)?
-- Who would edit "DCAM 2"?
-- What should be done with the existing "DCAM family" of specifications?
3. DCMI deprecates DCAM abstract syntax and embraces RDF abstract syntax
-- A "product of its time"
-- Henceforth promote RDF abstract syntax
Questions
-- Are there users of DCAM that would be negatively impacted?
-- What should be done with the existing "DCAM family" of specifications?
Status of each document
Change of DCMI message
-- What is an "application profile", if not based on DCAM, Singapore Framework,
and DSP?
4. DCMI does nothing - DCAM is simply left untouched
-- No changes to DCAM or DSP or clarification of their statuses.
-- DCAM and DSP are in effect "frozen" and de-emphasized, with no particular explanation.
Questions
-- Will DCMI really stand behind continued "recommendations"?
-- What cost in reputation and credibility?
-- Issue: DCAM abstract syntax vs RDF abstract syntax
Should DCAM dissolve into mainstream RDF?
Are Descriptions and Description 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:notation, dcterms:title...)?
-- Issue: Application Profiles
Does RDF need a notion of Application Profiles?
What are the requirements?
Do profiles need to express constraints?
If not with DCAM, how to represent patterns of constraints at level of RDF graph?
-- Syntax pattern checks (patterns "in the graph" rather than "in the world")?
Something like Description Set Profile constraint language?
Are SPARQL query patterns enough?
-- OWL applied with closed-world Assumptions?
Given the Singapore Framework split between underlying vocabularies and
vocabularies as constrained in data formats...
-- At what level to express those constraints:
Wired into specification of underlying vocabulary?
Expressed as patterns matched to the data?
--
Thomas Baker <[log in to unmask]>
|