DCMI Architecture Forum telecon - 2010-10-07 - report
Agenda: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=DC-ARCHITECTURE;f5152fe2.1010
Attended: Tom Baker
Antoine Isaac
Stuart Sutton
Andy Powell
Pete Johnston
Mikael Nilsson
Dan Brickley
Ana Baptista
======================================================================
Summary of discussion (discussed options are attached below)
Antoine:
Where is Alistair's Son of Dublin Core? The reference given [1]
gets a 404.
[1] http://isegserv.itd.rl.ac.uk/sodc/SODC-0_2/
Answer:
http://web.archive.org/web/20080214232032/http://isegserv.itd.rl.ac.uk/sodc/SODC-0_2/
Mikael:
Thanks for the introduction. I like the very explicit
options and scenarios -- it is helpful to be very clear
about possibilities. Whatever scenarios chosen, it
is important to have a message. Instead of not saying
anything I would rather see positions taken. One of the
main questions is whether we need a DCAM that has a life
of its own.
Main question: Will we be able to create significant
community around specification with life of its own?
What is the value of doing so?
Historically, DCAM has filled role of bridging the gap btw
W3C world and other communities. Now those communities are
more knowledgeable, e.g., the library community (one of
the most important bases for building a community around
DCAM) - so there is less room for something "in between"
(as DCAM is). I would be in favor of either "DCAM 2"
or completely deprecating DCAM -- but this would need
an explanation of how and why. Should not just leave
a vacuum.
We do have in DC community: people using our terms without
using RDF at all -- the ISO standard, for example.
We need to be careful not to lose that part of the DC
community - retaining the simpler interface to Dublin Core.
I don't think DCAM is an important factor in that part
of the community. Rather, gathering point is the terms.
Andy:
This is a good set of options. 3 and 2b are viable ways
forward. Might be wider political questions around 3 - not
sure how easy it would be to do.
Option 4 is a consideration because DCMI is so short on effort.
Alot of work on 3 and 2b. If we go down either one of those,
need to make sure we have the effort to do so.
Ana:
Agree with Andy on 3 and 2b. What would be the impact of
changes (3 and 2b) on the community -- big differences
between the two. Need to know how much people are
using DCAM.
Andy:
In terms of impact, 2b and 3 are very similar -- 2b is
just a stepping stone to 3 -- so any work in interim,
with a short "DCAM 2" specification, people would need
to anticipate deprecation. Would be easier to carry
community with us with 2b for softer, political issues.
Ana:
Agree with Andy. Need to re-think -- things would happen
more quickly with 3.
Andy:
Option 4 is similar to 3 - acknowledges that world has
moved on around us. People are interested in RDF anyway.
Difference between 4 and 3 is the extent to which we
tidy up in the DC community. Because effort is short,
4 is worthy of consideration.
Dan:
Not much to add to previous. Agree with Andy, looking at history
and amount of effort, inclined to 4. With application profiles, we
can take very pluralist approach - not one single technology for
doing this. Also DC as a community has conference series - a way of
sharing these different approaches to application profiles.
Mikael:
Agree regarding application profiles. I'm not sure we need
a single notion. It's probably a good idea to open up to
different ways because people have different requirements.
Singapore Framework would remain useful because it maps
out how we see people documenting profiles. The main issue
is not really application profiles. The core issue is the
models -- the DCAM and the RDF model, their relationship
to DC community and DC terms. That is the main issue.
Stuart:
Agree - 2b and 3. But 4 is problematic, precisely
because we have "fallen between two stools"; doing or
saying nothing would distance people more and more.
Andy:
Options 2b and 3 have to do with how best people currently
active in DC community can contribute to future of Linked
Data and RDF. Those contributions will be made elsewhere
than DCMI. DCAM-related modeling guidance (rdf:value, etc)
is not a huge issue and should be off the table for now.
If the wider community needs answers to such questions,
they will be addressed there. DCMI is no longer a place
where these sorts of question are addressed.
Mikael:
That is the core issue. What should DCMI's focus be?
Suggest focusing on the core asset, the vocabulary -- it
is used everywhere. People are solving the syntax issues
elsewhere -- there is no reason to duplicate that work.
the Linked Data community is where things are happening.
Concentrate DCMI resources on developing and maintaining
the use of the core vocabulary.
Tom:
The Usage Board has been discussing a proposal about its
future:
-- Drop the review of application profiles.
-- Create a small vocabulary management group, recruiting from
other RDF vocabulary maintenance communities, to:
-- Create new properties informed by semantic search-engine analysis
of emerging usage patterns and apparent gaps
-- Create alignments with other vocabularies (e.g., between
foaf:maker and dcterms:creator)
-- Best practice for publishing DCMI Metadata Terms as linked data.
-- Review long-standing practices such as how DCMI Metadata Terms
are versioned.
-- Create a small group for reviewing user guidance material
related to DCMI Metadata Terms -- e.g., the revised User Guide,
FAQ, Glossary. Look for ways to maintain these documents better
as living wiki documents and to link examples in the user guide
to the main DCMI Metadata Terms document.
Pete:
Agree with Mikael's point about focus. One of my concerns: getting
back to core vocabulary management. Need to be taking advantage of
work others are doing instead of having DCMI variants for things
like syntax; there is plenty of good syntax work out there to use.
Mikael:
Discussion in the Usage Board is interesting. With the
rise of Linked Data, we suddenly have very interesting
world where new kinds of resources are coming online
and being described. These repositories often use their
own custom properties. New terms could be generalized
from these sources. Should not be afraid of extending
DCMI Metadata Terms. Interesting to see what people
are using and make DCMI properties; this would make DCMI
more relevant. Also, if we decide not to work much on DCAM
and DCAP, then looking at Interoperability Levels, we have
focus on Levels 1 and 2. What you are describing is RDF
usage of terms. But we also have usage in areas where RDF
not used. While we should not standardize in the non-RDF
space, it should be covered by the documentation effort.
Many projects need simple properties to use, and this
should be encouraged.
======================================================================
Scenarios for future development of DCAM (discussed above)
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]>
|
