DCMI Architecture Forum - report - telecon 2010-03-19, Friday
Attended: Tom Baker (chair), Pete Johnston, Mikael Nilsson, Manu Sporny
(for the HTML5 discussion)
-- DCMI feedback to HTML5 Working Group
Discussed draft:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1003&L=DC-ARCHITECTURE&P=16425
ACTION: Pete to suggest one or two points from [1] to add
to the draft HTML-WG feedback statement. Specifically, the
statement seems to be limited to issues around "a mechanism
to encode RDF triples using <meta> and <link> elements".
There should be an extra sentence making clear that DCMI's
interest in syntax is not limited to <meta> and <link>.
Manu also suggests we take the opportunity to make clear
that Dublin Core is not just about describing documents
(a common perception), but in principle any other type of
creative work.
After revision, Tom will submit the statement with a short
cover letter citing [1], which discusses various issues in more
detail than the draft statement and which some members of the
WG may be interested to read.
[1] https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1003&L=DC-ARCHITECTURE&P=1429
DCMI currently generates its representations of DCMI
metadata terms (both the Web pages and the schemas) from
a common source using XSLT transforms (aka the Vocabulary
Management Tool, or VMT). While we would be ill-advised to
make available the Subversion project for our production
code for contributors from the general public, we could
perhaps create a Google Code project with a copy of the
VMT source. Members of the RDFa community may be able
to help us tweak the XSLT transforms to generate our DCMI
Metadata Terms documents with embedded RDFa.
-- Architecture Forum Work Plan
-- Proposed Task Group "DCAM Made Simple"
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1003&L=DC-ARCHITECTURE&P=17020
Mikael will replace Tom as leader of this Task Group.
Pros and cons of the handle "DCAM Made Simple" were
discussed - a decision on this will be deferred for when
the document is written. The authors agree that the
external interface of DCAM (i.e., the Description Set
Model) per se should not change. The "DCAM2" project
is about changing the message, not the technology.
The DC-RDF specification should in effect be folded into
DCAM2, making DC-RDF obsolete as a separate document.
Proposed changes in the use of rdf:value (versus
skos:prefLabel) and dcam:VocabularyEncodingScheme
(versus skos:ConceptScheme) could have an impact on
implementers of the DC-RDF specification, but the authors
do not believe this will create problems in practice.
-- Proposed Task Group "Interoperability Revisions"
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1003&L=DC-ARCHITECTURE&P=17543
The participants resolved to focus for now more on
DCAM2 than on "Interoperability Levels". As the
goal is to make DCAM2 more readable and accessible,
the revised introduction to DCAM2 should contain
language that enumerates the advantages of moving to a
linked-data approach and present DCAM as a syntax for
packaging linked data in records, thereby addressing
the shortcomings of "Interoperability Levels" in terms
of messaging. We will focus on getting the message
right in the DCAM2 draft for now, then consider revising
"Interoperability Levels" at a later date, but for now
take them one at a time. The language and message of the
DCAM revision should both follow from and contribute to
the broader discussion about DCMI's strategic direction.
-- Syntax guidelines
-- DC-HTML revisions
Pete will make corrections as errata to the current version and
circulate the link for review prior to publication.
-- DC-DS-XML - advance to DCMI Recommendation?
We will leave DC-DS-XML as a Proposed Recommendation
for now, moving the specification forward only if a
clear need emerges. One possible approach in future
could be to use RDFa attributes and CURIEs as per
the RDFa 1.1 specification under development.
-- Is the further development of syntax guidelines in
Architecture Forum sustainable (or desirable)? The
current program for developing syntax specifications
dates from a time (e.g., five years ago) when there
was little else on offer, so it filled a need.
The need is still there, and the need is continually
evolving, but DCMI's human resources in this area
are very limited so our role should be more to point
people towards specifications developed elsewhere,
such as similar expressions of structural constraints
for RDFa profiles. One possible venue for such guidance
could be the (experimental) DCMI blog.
That said, the 2003 DC-XML-GUIDELINES specification
is an important problem because it remains quite
popular and continues to be implemented despite its
known limitations with regard to compatibility with
linked data (as discussed in [1]). If resources could
be found, this document could perhaps be replaced --
not with a specific XML format, but with guidelines
that help people design their own XML schemas
for compatibility with triples.
[1] http://dublincore.org/documents/dc-ds-xml-notes/
-- Other
-- The participants agreed that DCMI should re-orient towards pointing
implementers to developments elsewhere, such as RDFa argots, or
various new guidelines for coining URIs and maintaining vocabularies,
as they become known to us. Again, a DCMI blog would in principle be
a good channel for such guidance.
-- Regarding equivalence between dcterms:creator and foaf:maker, the
participants agreed that for the case considered, in which the two
properties clearly mean the same thing, either of two approaches
would be appropriate:
-- mutual owl:equivalentProperty statements (FOAF already having made
an owl:equivalentProperty statement)
-- complementary rdfs:subPropertyOf statements, which together add
up to the semantic equivalent of owl:equivalentProperty, but
achieve this "socially" and with ontologically weaker statements
Tom will work with Aidan Hogan on drafting a rationale
for the latter. A final decision will rest, in any case,
with the Usage Board.
-- Revision of PURLs with 303 redirects
Whether we stay with separate HTML and RDF/XML
representations of DCMI Metadata Terms or move towards
using RDFa in one document, the PURLs will need to be
changed to return 303 instead of 302. It is not clear
whether this can be done at the level of a base URI or
needs to be done separately for each individual URI.
If 303 redirects need to be defined for each URI, it
is not clear whether this would need to be done by hand
each time a new Terms document is issued (tedious work!)
or could be automated with a batch process.
--
Thomas Baker <[log in to unmask]>
|