Title: Usage Board meeting in Seoul - 2009-10-16 - Meeting notes
Identifier: http://dublincore.org/usage/minutes/2009/2009-10-16.dcub-meeting-seoul-minutes.html
Created: 2009-11-14
Attended: Tom Baker (chair), Akira Miyazawa, Andrew Wilson, Joe Tennis,
Julie Allinson (remote by Skype), Pete Johnston (remote by Skype), Stefanie Ruehle,
Makx Dekkers (first hour, ex officio)
Guests: Raju Buddharaju
Agenda: http://dublincore.org/usage/meetings/2009/10/seoul/
Packet: http://dublincore.org/usage/meetings/2009/10/seoul/2009-09-13.meeting-packet.pdf
----------------------------------------------------------------------
Follow-up on Accessibility
Tom: Decision was posted - Liddy has posted replies on a number
of DCMI lists.
There was an interesting and productive meeting at DC2009 with
Tom, Liddy, and Makx discussing the Accessibility proposal with
Eric Miller and David Wood, who both found the proposal
interesting. They did not disagree with the decision to reject
but thought it could be useful to have a DC property for
accessibility.
They expressed interested in seeing a test implementation of the
idea showing what one could do with an accessibility property -
leaving open the question of the property name and the need for
some wordsmithing.
Pete: I agree that implementation would be good. Was almost
thinking we should require this for any term proposals -- but
that's a separate discussion.
Tom: Create a reference document with footnotes citing prior and
related work. Tom would like to see the proposal go to the
mailing lists and see what support is shown by the Community.
Question for UB is whether we would consider a new proposal for
an 'accessibility' property.
Andrew: My concern - how does UB consider new term proposals.
Should we be adding new terms at all? I am not saying we should
rule this out. Spoke with someone this morning who said our
process is not clear enough. Proposals result in rejection, so
communities lose interest.
Makx: A few issues for discussion, e.g., in Oversight Committee.
What do we want in terms of proposals - a profile? a profile
with terms? People have the impression that the UB is very
careful. The current approach seems to say: "No, unless" and
"We need to be convinced". The MARBI approach has been: "Yes,
unless" and "Only if we think it is really wrong". People also
think that of APs because SWAP was rejected. People see the
final verdict. Who would make the effort if they are not sure
they have a chance? Apart from question of what we want to
review, there is the question of the maintenance effort we take
on. Makx suggests a more positive approach.
Pete: SWAP was not the only AP considered. The Collections AP
was approved. As for new terms - is this about UB/DCMI
"endorsement"? If I were doing it now I'd find my own URI
space, publish term, and just get on with it.
Pete: [DCMI Metadata Terms] is not a functional set of terms -
just a set of terms. Question: what is the set of terms and
what is the purpose of managing them as a set?
Joe: Thought when I joined that the UB would be dealing with
APs, but we're still dealing with legacy issues. Need to
prioritise and decide what our business is.
Pete: My two "or" aspects above were: persistence and
disclosure/discoverability (as well as endorsement).
Stephanie: Evaluate APs. The problem with terms is that some
are too granular (i.e., they are not cross-domain). New term
proposals have to fit the bigger picture.
Akira: The UB standard is a bit too high - there needs to be an
easier way for new terms to be established. The UB should be
focussing on APs. Question: what is DCMI terms and what are new
terms in APs?
Pete: It is easy to establish a new term - publish them in your
own URI space. Question: what is UB process adding to that? UB
commitment to reviewing and approval leads to publication on
DCMI website, thus the visibility of terms is enhanced. What
requirements are being satisfied by having terms approved by the
UB? Various aspects to the answer.
Makx: New term proposals are not problems but opportunities. If
a term isn't violating any principles then we should have it.
Pete seemed to be saying we don't want people to do this. The
UB is in danger of becoming useless to those in communities if
we don't accept new terms. Most of what is in the term set is
useful for people. Acessibility is one new term that could be
very useful and has a value to DCMI.
Pete: Not starting from the position that UB should say no -
trying to sort out what requirements the UB is meeting.
Tom: For APs, maybe bar is set too high re: persistence of
URIs. Time to change this position and lower the bar re URI
persistence.
Tom: "is it useful" as a criterion for evaluation. Eg
Accessibility - if the Community is to find this useful then
taking usefulness as a criterion is one way to proceed.
Generally not in favour of UB considering new term proposals.
But if we were to get a new proposal with an implementation,
with community support, then would consider it favourably.
Makx: I volunteer to write a short note about an alternative
approach. Our position should be "Yes, unless its stupid"
rather than "no unless its useful". Will prepare in next 3-4
weeks and submit to UB for discussion.
ACTION 2009-10-16: Makx to propose new UB approach to evaluating
proposals.
Tom: Difference between accepting something for review, and
accepting something. Resource concerns for UB.
Julie: Need to be conscious of size of proposal and amount of
work involved. Not useful for the group to spend hours and
hours on one proposal.
Raju: Most of discussion is about legacy issues.
Julie: I'd also add that we need to be clear about how the
proposal should be formatted and what is required from proposers.
Raju: Now we have a choice about whether new terms or APs. Need
to be clear about whether a proposal should be an AP or a
proposal for a new term.
Joe: If we are going to follow the lead proposed by Makx we need
to be very clear about what we think the review criteria are -
what is stupid...and what is not.
Julie: As part of review process for APs we review if new terms
are added or not. Part of the process could be whether the proposers
want the new term to be in DCMI namespace or not.
Tom: Let's wind this up - Makx has an action to make a proposal to UB.
----------------------------------------------------------------------
Administrative Components (Andrew)
Agenda says:
http://dublincore.org/usage/meetings/2009/10/seoul/acore.pdf
-- www.bs.dk/standards/AdministrativeComponents.htm
http://dublincore.org/usage/meetings/2009/10/seoul/.html/acore-email-digest.html
-- Task: Prepare a short review of ACore for discussion
in Seoul. What can or should the Usage Board say about
ACore? The review should discuss the possibility of
defining ACore as an application profile.
Andrew presents:
http://dublincore.org/usage/meetings/2009/10/seoul/2009-10-16.AdminMetadata.ppt
Andrew: Original A-Core, Iannella and Campbell, 1999.
Metadata set about metadata records. Very simple; no large
aims. Only 8 properties and 4 categories.
Hansen and Andressen added a "source" property, 2003. Added a
requirement that this metadata set be exchanged, so added
interoperability. They had a total of 23 categories - metadata
for entire record, change, and exchange. About the metedata:
identifier, source, scope, comment, location, language, rights,
dateRange, handling. About change and update activity - action,
name, email, contact, date, affiliation. About transmission and
interchange: database, transmitter, fileName, technicalFormat,
characterSet, bibliographic formation, resultFile.
Andrew: Have the feeling there are unnecessary properties - it
is too complex. For example, could drop
transmission/interchange.
Makx: Who is the 'we' that would do anything about this?
Andrew: Don't know.
Tom: Question is - what (if anything) should the Usage Board say
about A-Core? This is because there appear to be people who are
interested in this.
Makx: There is a proposal before the AB to look at Meta Metadata.
They could look at the A-Core work Andrew has done.
Andrew: If we talk to people about using this we should drop
transmission, and there's an ISO 19115 standard adopted by AGLS,
and maybe we don't do anything but point them to ISO.
Tom: I have more fundamental questions. I think this is an
application profile, where the properties are not specified, and
it's not clear what the domain model is. And this would clarify
a lot. The URIs are under purl.org/identifier. It looks like
an early rough draft of an AP. The purl doesn't work.
Makx: This is just what Michael Panzer is proposing. MP wants
to add a domain model and proper AP.
Pete: I agree with Tom. Andy and I both made comments on this on
the AB list back in 2003 but they were ignored.
Tom: I propose an action for Andrew to write a brief summary of
his work. Action on Andrew to write brief summary of A-Core,
and relate it to early work by Debbie and colleague, and make
few comments on the specific properties made in the ppt? Then
we can send an email message giving the context, saying that we
had a brief discussion in the UB.
Makx: I would do it other way around. when we discuss it
tomorrow. If we agree that we're setting up a Task Force, that
we tell them they need to use Andrew's work.
ACTION 2009-10-16: Andrew to send material to Panzer if the AB
approves the new Task Force on Meta Metadata.
----------------------------------------------------------------------
Errata and other changes to DCMI terms documentation (Akira)
Agenda says:
http://dublincore.org/usage/meetings/2009/10/seoul/.html/errata.html
This document includes some proposals to be decided formally
at the meeting (and documents some decisions already and in
the queue for publication). After the Seoul meeting, this will
be turned into a single decision document.
http://dublincore.org/usage/minutes/2008/2008-09-21.berlin-5Etc.html
The meeting notes for Berlin record the discussion of the literal
range for Title and Alternative title.
-- Task: Carefully check all of the proposed changes.
Write a very short summary of the rationale for assigning
a literal range to Title and Alternative title (using the
meeting notes above.
Pete's proposal to delete sentences from usage comments for dcterms:contributor,
dcterms:creator, and dcterms:publisher (see meeting packet p. 12)
RESOLVED - To delete the sentences from the usage comments as
per pp.12-13 of the meeting packet.
ACTION 2009-10-16: Tom make changes in DCMI Metadata Terms
declarations as per proposal.
ACTION 2009-10-16: Tom to publish the text in pp.12-13 of
meeting packet as decision text.
Range for dcterms:title - this is approved but a note is needed
Akira proposes the following rationale:
Note: In October 2009, DCMI specified the range as literal,
though there are some important uses with non-literal values of
"title". Main reasons are 1) Most applications use "title"
with literal values, 2) Literal range makes implementation
greatly simple. Those who want non-literal values can use
legacy http://purl.org/dc/elements/1.1/title.
ACTION 2009-10-16: Tom to wordsmith text, add to decision
document for DCMI Metadata Terms.
ACTION 2009-10-16: Tom to add range "Literal" to dcterms:title in
DCMI Metadata Terms.
Re: 2009-04-21 - maintanance correction (see meeting packet)
ACTION: Tom to change reference 15836-21003 to 15836:2009
Re: 2009-05-12 - documentation error (see meeting packet).
This action has been completed.
Re: 2009-05-19 question: should we extend the dcmi-terms page index?
ACTION 2009-10-16: Pete to look at XSLT for dcmi-terms page index.
Re: 2009-08-24 issue (see meeting packet)
ACTION 2009-10-16: Tom to correct URI
Re: 2008-10-15 issue (see meeting packet) - no action required.
Re: 2008-09-21 issue (see meeting packet)
ACTION 2009-10-16: Tom to correct RDF schemas
Re: 2009-07-23 - RDF schema proposed by Pete
Usage Board: APPROVED
ACTION 2009-10-16: Tom to add see also link to http://purl.org/dc/dcmitype/ (with final slash!)
Re: 2009-07-23 - Guidelines for Dublin Core Application Profiles (see meeting packet)
ACTION 2009-10-16: Tom to make correction regarding ISO639-2 as proposed
ACTION 2009-10-16: Tom to add resource class constraint
For both actions, Tom should first consult co-author Karen Coyle.
----------------------------------------------------------------------
Usage issues (Pete)
Agenda says:
-- Creator and Maker
http://dublincore.org/usage/meetings/2009/10/seoul/.html/dccreator.html
http://dublincore.org/usage/meetings/2009/10/seoul/.html/foaf-maker.html
-- Candidate issues for further discussion
http://dublincore.org/usage/meetings/2009/10/seoul/.html/dcidentifier.html
http://dublincore.org/documents/usageguide/appendix_roles.shtml
"Using Dublin Core Part 6: Using Agent Roles"
Simple Dublin Core
http://dublincore.org/usage/meetings/2009/10/seoul/simpledc-guidelines.pdf
-- www.intute.ac.uk/publications/eprints-uk/simpledc-guidelines.html
http://dublincore.org/usage/meetings/2009/10/seoul/.html/simpledc.html
-- Task: Follow dc-architecture discussion regarding
DC creator and FOAF maker and summarize discussion to
dc-usage by Friday, 2 October. Prepare bullet points
for discussing other issues (see above) in order to
identify topics for further discussion in the Usage
Board. Propose a one-paragraph glossary entry for
"Simple Dublin Core" for discussion. Could Agent Roles
be discussed in a short glossary entry?
Pete: usage issues that need to discussed:
1. Relationship between foaf:maker and dcterms: creator
2. Issues around dc:identifier and dcterms:identifier
3. Usage document
4. Agent roles
Agent roles won't be discussed here.
1. Relationship between foaf:maker and dcterms:creator
Slides sent previously
Using dc:creator - historical ambiguity in using this term:
inconsistent semantics in DC documents. So could be used with both
literal and non-literal values.
Led to data processing difficulties. To remedy this 'messiness',
FOAF community coined its own property foaf:maker.
Also asserted that foaf:maker could be used with dc:creator
provided dc:creator only used literals.
Now the situation is that foaf:maker says exactly the same thing
as dcterms:creator but this is not stated formally.
Proposal:
FOAF says
foaf:maker rdfs:subPropertyOf dcterms:creator .
DCMI says
dcterms:creator rdfs:subPropertyOf foaf:maker .
Andrew: why isn't it a problem that two things are sub-properties of each other?
Pete: It's a relationship statement in RDFS and both triples can be inferred -
from either statement both triples are able to be inferred. RDFS says this is OK.
FOAF to drop guideline re use of dc:creator with literal values (suggested by TomB).
At a technical level mutually sub-property assertions are not a probelm.
It enhances interoperability.
Not necessary technically to publish changes together but maybe good politically.
Few comments when posted to DC Architecture.
Pete: Andy Powell said we haven't made any such assertions before so this would
set a precedent - should we do it and would that mean we could be asked to make
more such assertions?
Andrew: Could it matter if we made more assertions of this type?
Pete: Might be useful to formally assert a number of other relationships.
Pete: We could either agree to make the assertion or go back to DanB.
Akira: Why isn't it just a synonym?
Pete: It could be but you can't say that in RDFS.
Pete: The sub-property assertion is almost the same as saying
they are synonyms. It might be possible to do it in OWL.
This might be a stronger approach
Tom: propose that UB take the initiative and formulate (if we
agree) a proposal to the send to the list for comments from the
OWL community.
Tom: would set an important precedent and is an important social
question with multiple vocabularies - no one is doing anything
about this so it would be good for DCMI to be proactive.
We could articulate clearly that this is an experiment and we
want to stimulate discussion about what's the best way to achieve
this (i.e., with mutual assertions). We should get reaction from
OWL and RDF communities about whether these type of declarations
are the right way to go.
Joe: Yes, this should be done but we need to think about the criteria
and state principles about why we are doing this now.
Tom: Will work with Pete on this.
ACTION 2009-10-16 Pete and Tom: Pete will investigate OWL
further to see whether it is possible to do this using OWL;
Pete and Tom will work up a post to email to the DC
Architecture and the Semantic Web community with cross
postings pointing to the DC Architecture list email.
Pete: I think the OWL construct to look at is
owl:equivalentProperty
http://www.w3.org/TR/owl-ref/#equivalentProperty-def
Pete: OWL property equivalentProperty may be the appropriate one.
Tom: question for the semantic web community.
2. Simple DC
Pete: The idea of simple DC is mentioned in a number of documents.
We can think of simple DC as a description set profile OR as a DC
application profile. I have no preference for the approach as long
as we are consistent. The core question is: which of the two DSP
"patters" do we want to use?
Tom: suggest we defer issue of 'dumb down'. Suggest we do both
legacy and modern - better than having either one alone.
Pete: agrees with this suggestion.
Stephanie: First question - should it be a DSP or a DCAP?
Pete: Thinks DSP is the best way to go
Tom: Functional requirements were deliberately underspecified at the
beginning. This allowed DC to get going. Shouldn't try to retrofit
functional requirements that would be necessary for an AP.
Julie agrees.
Tom: Suggest we keep on UB agenda but not with highest priority.
Stephanie: Problem with not having a high priority - should have a
high priority because it is needed for implementors now.
Tom: how about medium-term priority - agreement that we should have both
the proposed DSP.
ACTION 2009-10-16: Pete and Tom to write up explanation using two simple DSPs.
3. Use of dcterms: identifier
URI as a literal value
Tom: need to bookmark this when we look at FAQ and glossary
ACTION 2009-10-16: Tom and Pete to capture essence of the issues in a short
paragraph to take to DC Architecture.
Joe: Identity and location is an old issue (ie. raised some some time ago).
Not a big deal but seems to have connections with discussions about what a subject is.
We need to be explicit about our philosophy.
----------------------------------------------------------------------
Glossary (Joe)
Agenda says:
http://dublincore.org/documents/usageguide/glossary.shtml
"Using Dublin Core - Part 7: DCMI Glossary"
http://dublincore.org/beta/glossary/
Tom proposes that the glossary be written as a relatively short
document covering only major concepts that are characteristic of
Dublin Core metadata. The glossary is potentially a good place to
explain legacy issues, such as "dumb down" and "document-like object".
Candidate issues for inclusion (or summary) in a glossary:
http://dublincore.org/usage/meetings/2009/10/seoul/.html/dumbdown.html
http://dublincore.org/usage/meetings/2009/10/seoul/DumbDownNotes.htm
http://dublincore.org/usage/meetings/2009/10/seoul/.html/dlo.html
http://dublincore.org/usage/meetings/2009/10/seoul/IssuesWithCoverage.htm
-- Task: Identify which of the terms in the old glossary
are most important for describing the "Dublin Core style"
of metadata. For those most important terms, suggest bullet
points for what a modern glossary entry should say. Flag any
obvious gaps -- DC terminology that would need to be covered
in a glossary, such as the "candidate issues" above (and suggest
bullet points).
Tom: Issues that could be covered in a glossary include pre-DCAM vs post-DCAM,
prescriptive vs. descriptive. Two different functions of glossary: the past
and what is now. Should be a small document.
Joe: Suggest two glossaries. One post-DCAM glossary and one for
the legacy stuff which is pre-DCAM, with cross-references
between the two. The InterPARES Project [1] did this with
digital archives.
[1] http://www.interpares.org/
General point: one prescriptive and one descriptive glossary.
One will be a dictionary - that will be pre- and post-dcam.
90% of the old glossary will not go in the new one.
ACTION 2009-10-16: Tom to carry the glossary forward.
----------------------------------------------------------------------
Frequently Asked Questions (Julie)
-- Legacy FAQ
http://dublincore.org/resources/faq/
-- DCMI Mixing and Matching FAQ (Andy Powell, 2005)
http://www.ukoln.ac.uk/metadata/dcmi/mixing-matching-faq/
-- Candidate FAQ
http://dublincore.org/usage/meetings/2009/10/seoul/.html/range.html
-- Task: Identify which questions are still really
frequently asked. For those questions, prepare bullet points
proposing current answers. Propose an answer to the
frequently asked question about the difference between
dc:creator and dcterms:creator.
http://dublincore.org/usage/meetings/2009/10/seoul/2009-10-07.pete-simple-dublin-core-text.pdf
http://dublincore.org/usage/meetings/2009/10/seoul/2009-10-07.pete-simple-dublin-core.mbox
http://dublincore.org/usage/meetings/2009/10/seoul/2009-10-16.dcterms-title-decision.txt
http://dublincore.org/usage/meetings/2009/10/seoul/2009-10-16.dcub-fmaker.ppt
http://dublincore.org/usage/meetings/2009/10/seoul/2009-10-16.dcub-issues.ppt
http://dublincore.org/usage/meetings/2009/10/seoul/2009-10-16.dcub-meeting-notes-raw.rtf
Tom: See document Julie send some hours ago [*]. We should also
consider the new Web pages. The role of the FAQ is to show the
DC-specific jargon like dumb-down principle, qualifiers etc.
For example, what is the difference between dcmes and dcmi
terms.
[*] http://dublincore.org/usage/meetings/2009/10/seoul/2009-10-16.FAQ-julie.doc
----------------------------------------------------------------------
Julie: Number 1 is not used any longer
Yes - 1. What is metadata?
The simplest definition of metadata is " structured data about data."
Metadata is descriptive information about a resource whether it be physical or
electronic. The underlying concepts behind metadata have been in use for as
long as collections of information have been organized. Library card catalogs
represent a well-established example of metadata for resource discovery.
Metadata can be generated either "by hand" or derived automatically using
software.
----------------------------------------------------------------------
Julie: Numbers 2 to 5 not really used any longer.
No - 2. Where is the metadata on the Dublin Core website? [does
anybody actually ask this?]
No - 3. What is a resource?
No - 4. What is resource discovery?
No - 5. What is the Dublin Core Metadata Initiative? [this is on the
homepage, who on earth would miss that!]
----------------------------------------------------------------------
Julie: Number 6 for the glossary and used for the introduction of using dc
Yes - 6. What is the Dublin Core?
The Dublin Core Metadata Initiative develops and maintains specifications in
support of resource description. These include the DCMI Metadata Terms,
which includes the classic Dublin Core Metadata Element Set, the DCMI Type
Vocabulary, and resource classes used as formal domains and ranges, along
with supporting documents, usage guides, the Dublin Core Abstract Model and
other model-related specifications, and a set of syntax guidelines for encoding
Dublin Core in HTML, XML and RDF.
Further information: http://dublincore.org/documents/
----------------------------------------------------------------------
Julie: Number 7 dc simple and qualified should be part of the glossary (old)
No - 7. What is the Dublin Core Metadata Element Set?
----------------------------------------------------------------------
Julie: Numbers 8-10 not used any more.
Julie: Number 8 answer has to be: why use dc in various meanings = multiple questions
Change - to "Why use Dublin Core?" 8. Who can benefit from
using the Dublin Core Metadata Element Set? Dublin Core offers
a means of describing resources in a standard way. It is
particularly useful where interoperability with other systems is
important.
----------------------------------------------------------------------
Change - to 'What is Simple Dublin Core?'
9. What is the difference between "Simple" ("unqualified") and "Qualified" Dublin Core?
"Simple" Dublin Core refers to the Dublin Core Metadata Element Set Version
1.1, a set of 15 metadata properties for describing resources.
Further information: http://dublincore.org/documents/dcmi-terms/
----------------------------------------------------------------------
Add - "What is 'Qualified' Dublin Core?"
The phrase "Qualified" Dublin Core is a legacy term often used to refer to the
extended set of properties now maintained by Dublin Core.
----------------------------------------------------------------------
Add - what are Dublin Core Application Profiles?
In current practice, Dublin Core is more focussed on the development of
"application profiles" than on registering new metadata properties. A Dublin
Core Application Profile defines metadata records which meet specific
application needs while providing semantic interoperability with other
applications on the basis of globally defined vocabularies and models.
Further information: http://dublincore.org/documents/profile-guidelines/
----------------------------------------------------------------------
No - 10. Should I use Simple or Qualified Dublin Core?
No - 11. How do I begin implementing the Dublin Core Metadata Element Set?
----------------------------------------------------------------------
Yes - 12. What is the relationship between the DCMI and other Internet
standards groups? [keep text if this is this still correct?]
----------------------------------------------------------------------
No - 13. Was the Dublin Core intended to be used only for digital or
Web-based resources?
No - 14. How is Dublin Core metadata used?
----------------------------------------------------------------------
Julie: Number 15 will stay
Yes - 15. How is Dublin Core metadata stored?
Dublin Core can be stored as part of the HTML header of a web resource, as an
XML or RDF document, or can be mapped into a database structure.
----------------------------------------------------------------------
Change to - "Can I embed Dublin Core metadata within my HTML
documents?" 16. How can I embed Dublin Core metadata within my HTML documents?
Yes. See http://dublincore.org/documents/dc-html/
----------------------------------------------------------------------
No - 17. What is the relationship between Dublin Core Metadata and RDF and XML?
----------------------------------------------------------------------
Change - to "What is the Dublin Core Abstract Model" 18. What is the
Dublin Core data model?
The Dublin Core Abstract Model (DCAM) specifies the components and
constructs used in Dublin Core metadata. It defines the nature of the
components used and describes how those components are combined to create
information structures. It provides an information model which is independent
of any particular encoding syntax.
Further information: http://dublincore.org/documents/abstract-model/
----------------------------------------------------------------------
No - 19. How do I participate in discussions about the Dublin Core?
No - 20. What is the maximum length for each field in Dublin Core?
No - 21. What is an attribute-value pair?
No - 22. What is the Warwick Framework?
No - 23. What search-engines support the Dublin Core?
----------------------------------------------------------------------
Julie: Number 24 maybe stay.
24. Can I add a new element to Dublin Core? [a. yes, but you don't
necessarily have to, just declare it]
New properties can be formally considered by the Dublin Core Usage Board,
although creators of Dublin Core Application Profiles are free to define and
declare their own metadata properties, or to use properties from existing
schemes.
Section 2.5 of the following document specifies what constitutes a "valid"
metadata property: http://dublincore.org/documents/profile-review-criteria/
----------------------------------------------------------------------
No - 25. What is the Open Metadata Registry?
No - 26. How do I store proper names in Dublin Core?
? - 27. DCMI Intellectual Property FAQ
----------------------------------------------------------------------
Yes - 28. What is the "Dumb-Down" Principle?
[This needs discussion]
----------------------------------------------------------------------
Julie: Possible candidates for staying are 29 and 30.
Change - to "Can I add a new property to Dublin Core Metadata Terms?"
Change - to "Can I use controlled vocabularies for different metadata
properties?" - 29. How can I use existing controlled vocabularies for DC
Subject metadata?
Yes. DCMI registers a number of vocabularies in DCMI Metadata Terms:
http://dublincore.org/documents/dcmi-terms/
----------------------------------------------------------------------
Change - to "Can I use vocabularies that are not approved by DCMI?" -
30. Can I use controlled vocabularies that are not approved by DCMI?
Yes. DCMI has registered registers a number of vocabularies but does not aim
to register all possible vocabularies. There are, of course, many others that are
equally legitimate, and it has always been our intent that communities of
expertise be able to leverage the value of such existing schemes in their
metadata. To promote interoperability, it is recommended that application
designers review registered controlled vocabularies for one that may be
suitable for their application.
----------------------------------------------------------------------
Yes - 31. What are the DCMI Namespaces?
Text as is
----------------------------------------------------------------------
Add - "What is the difference between dcterms:creator and dc:creator?"
[I don't know what the answer is]
Add - difference between literal and non-literal. Between VES and SES.
----------------------------------------------------------------------
Discussion
Julie: Separate the questions by what, how etc.
What questions really belong in the FAQ?
Pete Johnston: I'm just comparing with http://www.w3.org/2001/sw/SW-FAQ which
doesn't really have many "whwt is X?" questions
Thomas Baker: Usage notes instead of FAQ?
----------------------------------------------------------------------
Using Dublin Core - Elements and Qualifiers (Stefanie)
We considered:
-- http://dublincore.org/documents/usageguide/elements.shtml
"Using Dublin Core Part 4: The Elements"
-- http://dublincore.org/documents/usageguide/qualifiers.shtml
"Using Dublin Core Part 5: The Qualifiers"
-- http://dublincore.org/usage/meetings/2009/10/seoul/.html/usingdc.html
Comments by Pete on "Using Dublin Core"
Task:
"In Seoul, we will not have time to discuss all of the
examples for elements and qualifiers in Using Dublin
Core. Rather, the task here is to prepare bullet points
on general issues related to the examples, for example
the issue of literal versus non-literal values. Prepare
to discuss possible ways forward for Using Dublin Core:
what would need to be done in order to bring the
document up to date? Is a document at this level
needed, and what is its audience?"
Stephanie: Looking at Using Dublin Core chapters 1-3. Cannot
work just on elements without knowing what's going to be on the
Introduction. The document needs a new introduction, saying
what DC is and the principles and goals of DCMI. Historical view
of how we got the elements and terms. Localisation groups need
something simple for new implementers. Chapter 2: technical
issues, XML, RDF etc -- should be really short.
Pete: Maybe syntax should come at the end. DC is now seen as a set
of "properties" so not useful to talk about "elements".
Tom: A question: How helpful generally are the notes/guidelines for
the creation of content (included in many of the term descriptions)
in the current User Guide?
Stephanie: Useful but all examples are very bibliographically
focussed -- i.e., they deal with library materials almost
exclusively. Users need to be told that properties apply, in
principle, to any resource, not just bibliographical.
Tom: Can we take all the usage notes and put them in a wiki and let
people have a go at them for a while. Would that work?
Pete: FWIW, I think the FOAF document has a nice style of
guideline. But it is a bit variable. Some properties have
detailed guidance, others almost none.
See e.g. http://xmlns.com/foaf/spec/#term_currentProject
Tom: Examples to cover some of the more interesting cases rather
than everything in the guide.
ACTION 2009-10-16: Stephanie to write an Introduction for new
Guidelines, using Diane's contents list as the basis.
ACTION 2009-10-16: Stephanie to find examples for the
interesting (i.e. difficult) properties to clearly show their
use.