Dear all,
I would like to spend most of the call on alternative
scenarios for the development of DCAM, as outlined below (and
in the agenda). Are these the right scenarios and questions,
or are we missing some important possibilities?
I would also like to plan the discussion in Pittsburgh, for which I
attach some draft Powerpoint slides.
Tom
On Wed, Oct 06, 2010 at 07:55:02PM -0400, Thomas Baker wrote:
> 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]>
|