Identifier: http://dublincore.org/usage/minutes/2008/2008-09-21.berlin-1Libraries.html
Description: This is one part of the minutes for the Usage Board meeting
of 20-21 September 2009. See http://dublincore.org/usage/minutes/.
1. Review of properties proposed by the DCMI Libraries Community (Julie)
http://dublincore.org/usage/meetings/2008/09/berlin/terms-dclib/
http://dublincore.org/usage/meetings/2008/09/berlin/terms-dclib/robina-request.pdf
Background
Three terms needed for the DC Libraries Application Profile
were proposed to the Usage Board in 2002. In response, the
Usage Board recommended the use of existing terms. Subsequently,
however, the requirements that must be met before a "term"
can be referenced in a Dublin Core Application Profile were
clarified to the effect that elements in XML namespaces are
not directly usable as properties in an RDF sense (see [1]),
so in 2006 it was proposed to remove these three terms from
the DC Libraries application profile [2]. In 2008, the three
terms were re-proposed to the Usage Board in order to fill a
gap in a deployed application profile.
[1] http://www.ukoln.ac.uk/metadata/dcmi/dc-elem-prop/
[2] http://dublincore.org/usage/meetings/2008/09/berlin/terms-dclib/MODS_terms_in_DC-Lib_Proposal.pdf
----------------------------------------------------------------------
1.1 Date Captured
http://dublincore.org/usage/meetings/2008/09/berlin/terms-dclib/date-captured.pdf
http://dublincore.org/usage/meetings/2002/05/captured-date_prop.html - 2002 proposal
http://dublincore.org/usage/decisions/2002/2002-02.captured.shtml - 2002 decision
Issues: overlap with dcterms:created? One-to-one issues?
Proposal doesn't define concept of "capture" clearly.
Is this an attribute of the thing which is "being captured"
or an attribute of the thing generated by the "capture"
process? Intent is (almost certainly) the latter.
Possibly a useful subproperty of dcterms:created?
Would be instance of DCMI creating subproperty of existing
subproperty. But useful in illustrating appropriate use of
RDFS semantics.
Proposal framed very much in context of DC Lib DCAP; needs
to be framed in a more general form, while remaining useful
for original use context.
Questions:
1. Is it well-defined?
2. Is it a subproperty of dcterms:date?
3. Is it a subproperty of dcterms:created?
4. Should this property have a URI in a DCMI Namespace?
Akira: What is relationship to dcterms:modified? Is captured
a subproperty of dcterms:modified? Probably not.
Diane: We shouldn't add these properties to a DCMI
Namespace. Sets wrong precedent.
Tom: We aren't setting a precedent. Also offers opportunity
to highlight good design principles.
Tom/Pete: If dcterms:captured is subproperty of
dcterms:created, then may not satisfy the requirements of
the DC Lib DCAP (to distinguish date of content creation from
date of "capture").
Akira: Resources are often composite. Unclear whether
attributes apply to composite whole or to one of component
parts.
Conclusion: Proposal does not provide well-defined notion
of "captured", but based on our discussion, Option 3
(dcterms:captured as subproperty of dcterms:created) seems
most appropriate approach.
Issues: Meaning of "capture" is not clear: "digitisation" is
one case; "snapshotting" Web sites etc is another. Difficult
to generalise.
Andrew: related to isFormatOf - same content, different format.
ACTION (Andrew): To draft definition/comment for proposed
property in time to present for discussion with DC Lib
Community at their DC-2008 meeting.
----------------------------------------------------------------------
1.2 Holding Location
http://dublincore.org/usage/meetings/2008/09/berlin/terms-dclib/holding-location.pdf
http://dublincore.org/usage/meetings/2002/05/holding-location_prop.html - 2002 proposal
http://dublincore.org/usage/decisions/2002/2002-02.holdingLocation.shtml - 2002 decision
Other candidates: cld:isLocatedIn (no, domain-restricted);
agls:availability?
Diane: "Responsibility"? Specifically for management, access?
Stefanie: "Responsible" is not clearly defined.
Pete: Doesn't clearly distinguish location-as-place from
institution-as-agent.
Andrew: The agls:availability property
addresses exactly this problem. See
http://www.agls.gov.au/documents/aglsterms/#DCAGLSNamespaces
Tom: agls:availability seems a good candidate, but need to
explain rationale.
DECISION: Suggest use of agls:availability.
ACTION (Diane): To draft recommendation that DC Lib community
use the agls:availability property with literal value in
time to present for discussion with DC Lib Community at
their DC-2008 meeting. Text should point out difficulties of
proposed definition (e.g. ambiguity between organisation and
location) and provide our interpretation of intended function
of "holding location".
----------------------------------------------------------------------
1.3 Version
http://dublincore.org/usage/meetings/2008/09/berlin/terms-dclib/version.pdf
http://dublincore.org/usage/meetings/2002/05/description-version_prop.html - 2002 proposal
http://dublincore.org/usage/decisions/2002/2002-02.version.shtml - 2002 decision
http://dublincore.org/usage/meetings/2008/09/berlin/terms-dclib/MODS_terms_in_DC-Lib_Proposal.pdf
Problem: Currently FRBR-specific. Needs to be generalised.
Julie: Range should be literal. eprints:version would be
subproperty of this property.
eprints:version definition is:
A version number or version string associated with the resource.
Tom: Whatever definition we come up with, we need to check
with DC Lib Community that it meets their requirements.
Proposed (revised) definition:
A statement which distinguishes the described resource from
other resources of which it may be an edition, revision
or adaptation.
Proposed range: Literal
Proposed label: Version
DECISION: Agreed to present property as proposed for public
comment and finalise in telecon.
ACTION (Julie): To draft comment in time to present for
discussion with DC Lib Community at their DC-2008 meeting.
----------------------------------------------------------------------
2008-09-20 Mary Woodley report from DCMI Library Community meeting
At the DC Library Community meeting attendees were in favor of
accepting this approach. Corey and I had reached a similar
approach separately; that is, to reuse existing elements
that already existed that are DCAM compliant. I will send a
copy of our Powerpoint to you later today. I have names of 2
volunteers who want to work on the modelling aspects besides
Corey and myself: Jon Phipps and Myung-Ja K. Han (University
of Illinois at Urbana-Champaign)