Usage Board Barcelona
Date: Friday-Saturday, 16-17 March 2007
Agenda: http://stage.dublincore.org/usage/meetings/2007/03/barcelona/html/index.html
Meeting packets: http://dublincore.org/usage/meetings/2007/03/barcelona/2007-03-16.ub-agenda-barcelona.pdf
http://dublincore.org/usage/meetings/2007/03/barcelona/2007-03-17.barcelona-cdap.pdf
In attendance:
-- Usage Board: Diane Hillmann, Stuart Sutton, Makx Dekkers (ex officio),
Akira Miyazawa, Andy Powell, Joe Tennis, Tom Baker (chair)
-- Guests: Pete Johnston (Friday only), Raju Buddharaju, Jon Phipps (via Skype)
----------------------------------------------------------------------
1. Outstanding Actions (Tom)
[CONTINUES] ACTION 2006-10-01: Tom to replace the Principles
document at http://dublincore.org/usage/documents/principles/
with a page that copies the definitions of elements etc from
DCAM and includes a short text stating: that the document which
used to live here has been superseded by the DCAM. Update UB
page to say we do things in light of the DCAM.
[CONTINUES] ACTION 2006-10-01: Tom to look through DCMI site
and note those pages where a reference to the principles
document needs to be changed to a reference to the DCAM
as appropriate.
----------------------------------------------------------------------
2. Domains and Ranges (Andy)
Note: In the following section, wherever we say "resource" we mean
non-literal resource. See section on Problematic Properties.
Note: In Barcelona, the terms were taken out of order, starting
with "audience". In these revised notes, the terms have been put
back into their usual order.
-- DC-15 properties from /1.1/ namespace now declared also in /terms/
contributor:
AGREED: approved
coverage:
AGREED:approved
LocationPeriodJurisdiction:
AGREED: approve
Jurisdiction:
AGREED: approved
creator:
AGREED: approved
date:
AGREED: domain is approved, propose range as literal (go to comment with
this)
description:
AGREED: domain of non-literal resource and range of rdfs:resource
format:
AGREED: approved
identifier:
AGREED: approved
Reference:
AGREED: approved
language:
AGREED: the defintion of language should include computer languages, sign
languages, and written languages
ACTION: define language (Diane Hillmann)
SUGGESTION: system for communicating ideas and feelings using sounds,
signs, gestures, and marks
SUGGESTION: add a comment to say that it includes written, spoken, sign,
and computer languages
Language:
AGREED: see language above
publisher:
AGREED: approved
relation:
AGREED: approved
rights:
AGREED: approved
RightsStatement:
AGREED: change definition to:
A statement about the intellectual property rights (IPR) held in or over a
Resource, a legal document giving official permission to do something with
a resource, or a statement about access rights.
source:
AGREED: approved
subject:
AGREED: approved
title:
AGREED: domain is approved, range propose literal, and then send out for
discussion
type:
AGREED: approved
-- Terms which have always been in the /terms/ namespace
abstract:
AGREED: domain non-literal and range is rdfs:resource
accessRights:
AGREED:approved
accrualMethod:
AGREED: approved
AccrualMethod:
AGREED: approved
accrualPeriodicity:
AGREED: approved
Frequency:
AGREED: approved
accrualPolicy:
AGREED: approved
Policy:
AGREED: approved
alternative -
AGREED: domain is resource, range rdfs:resource
AGREED: go to comment because this is problematic property [see
Problematic Property section below]
audience -
AGREED: accept the domain of resource and range of AgentClass
AgentClass --
AGREED: approve the term with a change the definition of AgentClass to "a
group of Agents"
available --
AGREED: domain is resource, we don`t know what to have as range
bibliographicCitation --
AGREED: approved
BibliographicResource --
AGREED: approve with change to definition, changing "published resource"
to "documentary resource"
BibliographicReference --
AGREED: approved
conformsTo --
AGREED: approved
Standard
AGREED: approved
created
refer to available
dateAccepted
refer to available
dateCopyrighted
refer to available
dateSubmitted
refer to available
educationLevel
AGREED: approved
extent
AGREED: approved
hasFormat
AGREED: non-literal resources is both the domain and range so left
unspecified until Singapore
hasPart
AGREED: non-literal resources is both the domain and range so left
unspecified until Singapore
hasVersion
AGREED: non-literal resources is both the domain and range so left
unspecified until Singapore
instructionalMethod
AGREED: approved
isFormatOf
AGREED: non-literal resources is both the domain and range so left
unspecified until Singapore
IsPartOf -- isReferencedBy -- isREplacedBy -- isRequiredBy -- isVersionOf
AGREED: non-literal resources is both the domain and range so left
unspecified until Singapore
issued
AGREED: domain is ok, querying the range
license
AGREED: approved
mediator
AGREED: approved
medium
AGREED: approved
modified
AGREED: domain is ok, propose range as literal (go to comment with this)
provenance
AGREED: approved
references
AGREED: non-literal resources is both the domain and range so left
unspecified until Singapore
replaces
AGREED: non-literal resources is both the domain and range so left
unspecified until Singapore
requires
AGREED: non-literal resources is both the domain and range so left
unspecified until Singapore
rightsHolder
AGREED: approved
spatial
AGREED: approved
Location:
AGREED: approved
AGREED: change definition to "a named place or spatial region"
tableOfContents:
AGREED: rdfs:resource as range
AGREED: not a case where we mean non-literal resource (because
description allows images)
[may not have captured all approved 1.1 above, e.g., I did capture
Location]
temporal
AGREED: with change in the definition Period
Period
AGREED: change definition to "interval of time that is named or defined by
its start and end dates"
AGREED: this is broader than the range of date and its subproperties and
should be noted
valid
AGREED: domain is ok, propose range as literal (go to comment with this)
-- Problematic properties
ISSUE: A title with multiple encodings is different from
multiple title statements.
ISSUE: When domain is stated to be rdfs:resource in /terms/
part of the Domains proposal we intend it to mean non-literal
resource because the meaning of rdfs:Resource is broader
and includes literals.
ISSUE: Where the domain and range is resource, we can
either say nothing, or we can say rdfs:Resource (which
is stating the obvious) -- this is related to our actions
related to specifically stating non-literal resource.
ISSUE: Because we have inverses in the isFormatOf type
properties, we need the same class at both ends of the
inverse -- therefore we should make all non-literal
resources (TBA).
AGREED: We are going to propose that range of description,
abstract, and table of contents is rdfs:resource knowing
that this causes OWL-DL incompatability for these properties
- this will go out for comment - we're asking if this is
reasonable to do this for these three properties.
AGREED: We need a class and will define a class of
non-literal resources for both domains and ranges.
ACTION: Add a new class of non-literal resource to the wiki,
use as domain and range as appropriate (Andy).
AGREED: Usage of this [non-literal] class for domains
should be part of the next comment period.
ACTION: Investigate whether owl:Thing is a suitable thing
for defining a class of non-literal resources (DONE). [Tom
later adds, from memory: We looked at the OWL spec and the
formal semantics seemed worryingly opaque.]
ACTION: Transcribe easel graph into the meeting (Tom and Andy
have pictures) (Tom)
ACTION (for lack of volunteers, by default Tom): write a
proposal capturing the issue of string, unspecified, and
thing for the problematic DCTERMS properties (title and its
subproperties, date and its subproperties, and description
and its subproperties). Taking the following position:
1. Title and its subproperties as literals [check notes]
2. Date and its subproperties as literals
3. Description and its subproperties as range = rdfs:resource
Then send this proposal out for public comment. There
are two audiences for this comment: (1) multiple script
communities and (2) SW community asking: best practice for
unspecified ranges. Note that we will use the non-literal
resource in all cases where the domain of our properities
is listed as rdfs:resource (in the proposal).
-- Undeclared legacy DCTERMS classes (SubjectScheme, etc, p.64)
http://dublincore.org/usage/meetings/2007/03/barcelona/SubjectScheme.txt
ACTION: Tom will write a paragraph about these placing them in
historical context (Tom).
-- Term type of existing encoding schemes (p.65)
http://dublincore.org/usage/meetings/2007/03/barcelona/Encoding-schemes.txt
AGREED: We need a deeper level of description/differentiation
between VES and SES, including definitions.
If you have a something already, how do you tell if it is VES or SES. If an ES
tells you what a value string it it's a SES. If ES defines a class of values,
then it is a VES (e.g., concepts).
For example, if you develop a list of educational levels, and if you define a
list of strings, then you're defining an SES. If you define a set of concepts
and assign URIs to them (as best practice), then you're defining a VES.
Best practice in this scenario is to define a set of concepts with URIs rather
than a set of strings.
ACTION (Stuart and Joe): Write a one-page explanation
differentiating VES and SES, vet with Pete Johnston,
and consider revisions to the Term Decision Tree:
http://dublincore.org/architecturewiki/TermDecisionTree.
(Note: the difference is basically String vs. Thing.)
AGREED: DC-Education is a great test-bed for these concepts
SES is a datatype in RDF (
VES is a set not in RDF (effectively the same as conceptScheme in SKOS,
except it's not limited to concepts)
DISCUSSION:
VES is a set of concepts that, once in metadata, allows editors to handle
assertion by adding things to it
SES is a set of strings
PROPOSAL:
change the generic "encoding scheme" in DCTERM declaration and
documentation to "vocabulary encoding schemes" or "syntax encoding
schemes" following the classification on page 66 of the meeting packet.
VOTE:
AGREE - 4
DISAGREE - 0
ABSTAIN - 2
VOTE ANNULLED (after 30 seconds)
AGREED: with the categorization on page 66 except in the following cases
(which
PROPOSAL:
change the generic "encoding scheme" in DCTERM declaration and
documentation to "vocabulary encoding schemes" or "syntax encoding
schemes" following the classification on page 66 of the meeting packet.
PROPOSAL:
we interpret these things as where SES is a set of strings and VES is a set of
concepts:
Vote on individual schemes:
http://purl.org/dc/terms/ISO3166 SES 5 VES 1 ABSTAIN 0
http://purl.org/dc/terms/ISO639-2 SES 5 VES 1 ABSTAIN 0
http://purl.org/dc/terms/RFC1766 SES 5 VES 1 ABSTAIN 0
http://purl.org/dc/terms/RFC3066 SES 5 VES 1 ABSTAIN 0
http://purl.org/dc/terms/IMT SES 0 VES 5 ABSTAIN 1
----------------------------------------------------------------------
3. DCTERMS definitions and comments (Tom)
-- Proposal for changes to DCTERMS
http://dublincore.org/usage/meetings/2007/03/barcelona/DCTermsChanges.pdf
Audience = ok
Alternative=(has a typo)=ok
TableofContents=ok
Abstract=ok
Created=ok
Valid=ok
Available=ok
Issued=ok
Modified=ok
Extent=(need to correct comment)=ok
Medium=no changes
IsVersionOf=ok
HasVersion=ok with first revised definition, with adding
"A related resource that is" at the beginning
IsReplacedBy=ok, change which to that (and be consistent with DCTERMS -
ACTION: do a which hunt Tom))
Replaces=ok
IsRequiredBy=no (change to make parallel with Requires)
"A related resource that requires the described resource
to support its function, delivery, or coherence"
Requires= change to "A related resource that is required by
the described resource to support its function, delivery,
or coherence" drop 'content'
IsPartOf=change to "A related resource in which the
described resource is physically or logically included."
HasPart= change to "A related resource that is included
either physically or logically in the described resource."
IsReferencedBy= change to "A related resource that
references, cites, or otherwise points to the described
resource."
References=change to "A related resource that
is referenced, cited, or otherwise pointed to by the
described resource."
IsFormatOf= change to "A related resource that is
substantially the same as the described resource, but in
another format"
HasFormat=change to "A related resource that is
substantially the same as the pre-existing described
resource, but in another format."
conformsTo:
AGREED: approved
spatial:
AGREED: approved
temporal:
AGREED: approved
mediator:
AGREED: definition approved, comment should be a list in this case:
In an educational context, a mediator might be a parent,
teacher, teaching assistant, or care-giver
dateAccepted:
AGREED: approved
ACTION: delete "freestanding property label" (Tom)
dateCopyrighted:
AGREED: change defintion to "Date of copyright."
ACTION: delete "freestanding property label" (Tom)
dateSubmitted:
AGREED: approved
ACTION: delete "freestanding property label" (Tom)
educationLevel:
AGREED: change the definition. remove "audience" in the definition, and
replace it with "a class of entity" and remove "its", so it reads: "A class of
entity, defined in terms of progression through an educational or training
context, for whom the resource is intended."
JUSTIFICATION: parallel construction
accessRights:
AGREED: change comment to: "Access Rights may include information
regarding access or restrictions based on privacy, security or other policies."
- this substitutes policies for regulations
bibliographicCitation:
AGREED: approved
license:
AGREED:remove comment
JUSTIFICATION: we don't say anything about value URI in any other
comment AND it's an application profile issue as to whether or not a value
has a URI, therefore we don't need the Creative Commons example
rightsHolder:
AGREED: remove comment
provenance:
AGREED: approved
instructionalMethod:
AGREED: approved
accrualMethod:
AGREED:approved
accrualPeriodicity:
AGREED: approved
accrualPolicy:
AGREED: approved
LCSH:
AGREED: change definition: "The set of concepts defined by the Library of
Congress Subject Headings"
MESH, LCC, DDC, UDC
AGREED: change definition to start: "The set of concepts..."
DCMIType
AGREED: change to "A set of concepts used to categorize the nature or
genre of the resource."
ACTION: Tom to add a change note that there was systematic change
"content of the resource"
IMT:
AGREED: change definition to "Set of concepts defined by IANA used to
indicate the media type of the resource"
ISO639-2:
VOTE ON: change to "The set of three-letter codes listed in ISO639-2 for the
representation of names of languages"
AGREE 5
DISAGREE 0
ABSTAIN 1
ISSUE: we recognize a set of concepts for language, however, interpreting
the ISO639-2 as a set of concepts would break the namespace policy
because ISO639-2 is a set of strings (defined by ISO and us).
ACTION: Joe will draft a document discussing issues related to principles
and purpose of UB decision-making
RFC1766:
AGREED: change to "The set of tags, constructed according to RFC 1766, for
the identification of languages"
URI:
AGREED:change to "The set of identifiers constructed according to the
generic syntax for Uniform Resource Identifiers, as defined by the IETF"
ISSUE: because of the way RFCs work, they change and take on a different
number
Point:
AGREED: change to "the set of points in space defined by their geographic
coordinates according to the DCMI Point Encoding Scheme"
ISO3166:
AGREED: change to "The set of codes listed in ISO 3166-1 for the
representation of names of countries"
Box:
AGREED: change to "the set of regions in space defined by their geographic
coordinates according to the DCMI Box Encoding Scheme"
TGN:
AGREED: change to "the set of places defined by the Getty Thesaurus of
Geographic Names"
Period:
AGREED: change to "the set of time intervals defined by their limits
according to the DCMI Period Encoding Scheme"
W3CDTF:
AGREED: change to "set of dates and times constructed according to the
W3C Date and Time Formats Specification"
RFC3066:
AGREED: change to "The set of tags, constructed according to RFC 3066, for
the identification of languages"
AGREED: add comment "RFC 3066 has be obsoleted by RFC 4646"
NEW TERM
RFC4646
AGREED: add definition "The set of tags, constructed according to RFC
4646, for the identification of languages"
NLM:
AGREED: change to "The set of concepts defined by the National Library of
Medicine Classification"
ACTION: Tom change all encoding schemes to follow the LCSH change in
definition
ACTION: Tom to find "uses a controlled vocabulary", report to list, and
remove from comments.
NOTE: if interoperability is operationalized as keeping current encoding
schemes already in our namespace, then we should add new terms to keep
it up to date.
QUESTION: Do we need "qualifies statements"? [e.g., p. 57]
AGREED: remove "qualifies" statements and discuss encoding schemes in
application profiles only, not in dcterms
JUSTIFICATION: this kind of information belongs in an application profile
QUESTION: do we want to now formally declare subproperty relationships
for contributor, subject, and relation?
AGREED: yes for contributor and relation; no for subject [p. 41]
JUSTIFICATION: for contributor and relation = clarifies semantics
----------------------------------------------------------------------
4. DCMES finalization (Akira)
-- Topic page
http://dublincore.org/usage/meetings/2007/03/barcelona/Topic-nisoballot.txt
-- Summary of NISO ballot comments
http://dublincore.org/usage/meetings/2007/03/barcelona/Z39-85_Ballot_comment_responses.pdf
Task: respond to NISO based on comments, then put any editorial changes
out for DCMI public comment
ACTION: Akira and Tom to draft text in accordance with those changes
Comment 2 p. 67-68:
AGREED: adopt changes proposed
NOTE: check the Abstract Model
Comment 3 p. 68
AGREED: adopt changes proposed
Comment 4 p. 69
AGREED: comment starts: "spatial topic and spatial applicability may be..."
Comment 5 p. 71
AGREED: we will leave things as they are because it is not part of the
definition
JUSTIFICATION: the comment of 2001 was not intended to mean that
format should be used to record information about hardware and software,
rather the intent was that software could take decisions based on
infomration recorded in Format - for example the use of
Application/MS-Word as a value for Format can be used by software to
determine that Office is required to read the file, however, we recognized
that the sentence was abiguous and therefore decided to remove it, further
no negative feedback from DCMI Community. we've always seen
dimension as falling within the semantics of the format property.
Comment 6 p. 72
AGREED: adopt changes
Comment 7 p. 73
AGREED: change definition: "A related resource from which the described
resource is derived"
AGREED: leave the comment unchanged
Comment 8 p. 73-74
AGREED: adopt changes
Comment 9 p. 74
AGREED: we recognize this is confusing, and propose to remove the
comment completely
Comment 10 p. 77
AGREED: the comment as we had it was potentially misleading because
people might assume that "general category" is a subject category, which
was not intended
ACTION: Tom check 2004-2005 change
Comment 1 p. 67
AGREED: DCMES defines a set of terms. It does not define and application
in which those terms are used.
See http://www.niso.org/standards/resources/DC-NLM-vote.html
----------------------------------------------------------------------
5. Review of application profiles
-- Review guidelines (Stuart)
http://dublincore.org/usage/meetings/2007/03/barcelona/ProfileReviewCriteria.pdf
AGREED: The following are the three categories used to
evaluate application profiles that come before the UB:
1. Conforms to the DCMI Abstract Model (done - see Manzanillo notes)
2. Internal consistency
3. Documented according to our guidelines for application profiles
----------------------------------------------------------------------
-- Collection Description Application Profile (Joe)
-- Topic page
http://dublincore.org/usage/meetings/2007/03/barcelona/Topic-cdap.txt
-- Revised CDAP
see separate meeting packet 2007-03-17.barcelona-cdap.pdf
-- Usage Board feedback, December 2006
http://dublincore.org/usage/meetings/2007/03/barcelona/CdapFeedback.pdf
-- Table showing response to feedback
http://dublincore.org/usage/meetings/2007/03/barcelona/ComparisonRubric.pdf
-- Usage Board review - draft
http://dublincore.org/usage/meetings/2007/03/barcelona/CdapReview.pdf
New version received Saturday night, not much time to review.
Issue 1: data model, its role in the AP. They have
removed references to the AMCC that require dependency,
still a relationship.
p. 154 contains a reference, describes the relationships with the model, Joe
suggests clarification needed.
on p. 10 of the ap document, a UML-like diagram, describes their now
free-standing data model. A bit later there's a separate model of the layers.
Joe points out that there is no distinction between physical or digital
resources, both can have locations. Raju asks whether items (his example
was serials) can be spread across multiple collections, answer is ambiguous.
Issue 2. Document and scope, p. 88 of the packet. New
section, purpose and scope has been added.
Issue 3. Confusion between collections and "collections
of collections". Went back to one profile from two
separate ones, and confusing bits have been clarified.
Issue 4. Change of Label for "Collection-Description".
Aspect of confusion problem above. Have attempted to
identify terms better in their property list.
Issue 5. Conflation of unitary finding aids and
catalogs/indices Confusing use with the AP, generally
stems from AMCC model. Defined, but not in the
pictures, suggests it's a leftover from the AMCC model
dependency. Andy thinks this isn't necessarily a problem.
Other related issues are whether they're using "record"
and not indicating where it is defined, may be DCAM.
Issue 6: The term "content" is used in the definition
of item. Issues raised about location and the lack of
distinction between physical and digital items arise
again--is location useful for digital, UB thinks probably
not (p. 90 of packet)
Issues we did not bring up but they did:
-- Renamed AP
-- Other minor modifications
-- Vote
QUESTION: Conforms to the DCMI Abstract Model?
AGREE 4
DISAGREE 1
ABSTAIN 1
QUESTION:Is this internally consistent?
AGREE 5
DISAGREE 1
ABSTAIN 0
QUESTION: Is it documented according to our guidelines for application
profiles?
AGREE 4
DISAGREE 0
ABSTAIN 2
AGREED: It conforms.
ACTION: To draft a review that contains: (Andrew)
1. Descriptive piece which demonstrates that we have read the profile
and understood it
2. Present the result ("it conforms")
3. Then present considerations, e.g., acknowledge that
DCMI's DCAP guidelines are currently still a moving
target and that they have met the guidelines "such as
they are" or words to that effect.
ACTION: Tom will communicate these results to Sarah and Muriel
----------------------------------------------------------------------
-- DCAM Profile Model (Andy and Tom)
Andy reports on "Description Set Profile" meeting, 15 March, Barcelona
Criteria 1.0 for conforming AP
1. Conforms to the DCMI Abstract Model (DSP)
2. Internal consistency (e.g., DSP relationship to FR)
3. Documented according to our guidelines for application profiles
(totality of doc from below)
AP Model
1. Functional Requirements (desirable)
2. Domain Model (mandatory)
3. Description Set Profile (mandatory)
4. Usage Guidelines (optional)
5. Encoding Syntax Guidelines (optional)
STATED REASONS FOR AN AP:
1. conform to abstact model = is one (perhaps not only) operationalization
of interoperability
2. encourage reuse of APs (through modular approach like in the DSP)
3. AND reuse of individual properties
4. document how metadata is used in a particular application
NEED: functional requirements for application profiles
----------------------------------------------------------------------
6. USAGE BOARD PROCESS
-- Current process document
http://dublincore.org/usage/documents/process/
-- Notes from Stuart
http://dublincore.org/usage/meetings/2007/03/barcelona/Process_Doc_Revisions.txt
-- Proposal from Makx
http://dublincore.org/usage/meetings/2007/03/barcelona/2007-02-14.dcdir-process-makx.txt
Tom will start a discussion on dc-usage-bc.
----------------------------------------------------------------------
7. WORK PLAN
http://dublincore.org/usage/meetings/2007/03/barcelona/FrontPage.pdf
----------------------------------------------------------------------
8. RDA
See discussion paper by Diane et al
-- http://dublincore.org/usage/meetings/2007/03/barcelona/Framework_20070311.pdf
Not UB business - will discuss at dinner.
----------------------------------------------------------------------
9. AOB
Next meeting will be held Saturday and Sunday, 25-26 August 2007, in Singapore
http://conferences.nlb.gov.sg/dc2007/