Usage Board, Saturday 20 Sept 2008
==================================

Expected: Tom Baker, Diane Hillmann, Julie Allison, Andrew Wilson, 
          Stefanie Ruehle, Akira Miyazawa, Pete Johnston, (Joe Tennis)
Guests:   Stuart Sutton, Jon Phipps

09:00-12:00 Morning session

1. Review of properties proposed by the DCMI Libraries Community (Julie)
========================================================================

Background 

Three Terms proposed in 2002; UB recommended MODS terms (!),
but MODS terms not suitable for use in DC descriptions, so
2002 decision should be deprecated; now need to reconsider
initial proposal.

1.1 Date Captured

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.

Shelve for mmoment

== Coffee break ==

1.2 Holding Location

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

Pete: 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 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.

1.4 Date Captured (revisited)

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. 

== Lunch break ==

2. Review of properties proposed by the Accessibility (Andrew)
==============================================================

Andrew: Potential addition of property to AGLS has prompted submission.

Proposal is for one property only. Suggested VES will be owned by AGLS.

Potential issues of overlap with work of other groups (IMS, W3C).

Need clarity about range of property. Maybe more than one property required?

Tom: Co-ordinate development of property and VES with AGLS. 

Need good definition of property, clear specification of range.

RESOLVED: Co-ordinate development of property and VES with AGLS. Andrew to shepherd.

Step 1: Liaise with AGLS re co-ordinated publication of property dcterms:accessibility and AGLS VES.

Step 2: UB to ask AGLS to confirm desired VES.

Step 3: UB & AGLS to jointly agree natural language definition & formal range to express semantics of resource-valuerelationship. (Note: currently apparent overlap between values for "accessibility" and "accessMode" properties.)

Goal: Co-ordinated publication of DCMI property and AGLS VES along with simple usable documentation.

== Coffee break ==

3. Review of Scholarly Works Application Profile (SWAP)
=======================================================

Definition and scope: has been circulated and discussed. Tom: are we missing something about ongoing maintenance responsibility. Julie: There's a new person coming on who will be responsible, so presumably that's taken care of (should that go in?)

DSP Metadata Terms Reference: Julie and Diane confirm that the current wiki version is correct. Pete: the info:uri for bibliographicCitation should be identified as a Syntax Encoding Scheme. Julie: There's an option to provide and OpenURL opject.  Tom questioned whether it was formatted correctlY and Pete thinks so.  Tom: There's a more general question about this, and Ann Apps' document about Bibliographic Citation, and what SWAP does is consistent with this, Tom wants this to be more explicit in DCMI documentation. 

ACTION: Julie or Diane should write up a sentence for the review pointing out that the info:uri for the OpenURL Framework is nowhere declared as a datatype or SES, but that in our interpretation of the documentation (see citation in review) the use of the URI in this way is consistent with the concept of a datatype.

Constraints: Pete notes that the URLs Tom cites are incorrect--Tom got those from the XML source, which need to be corrected.

SWAP DSP Errata:
1) Remove trailing slashes from URL for Entity Type
2) Typographical errors
3) Remove VES constraint for IsExpressedAs etc.
4) Remove null values for Language
5) Type, Status and accessRights - use of VES should be optional
6) Revise SWAP use of dc:type for both expression entity type and resource type wrt property list constraint matching issue outlined below
7) Bibliographic Citation DC-Text example should have two statements rather than a single value string; and eprint-specific recommendation should read 'or' rather than 'and/or'

SWAP DSP Discussion Points:
1) Subject constrained to a single value string?

Agreed:
Point about VES constraints for Funder etc. fine as is.

Pete: DSP model permits use of both literal and non-literal values

ACTION: Tom to correct profile review criteria section on statement templates: [mandatory] property constraints - one of the following: ...

ISSUE: Is constraint 6.3 required?

ISSUE: Is it redundant to have a Value VES constraint in addition to a Value URI constraint, or good practice? Guidance on this point may belong in the application profile guidelines.

ISSUE: Rendering of the Wiki pages does not capture all of the DSP detail and uses different labelling.  It would be useful to hyperlink labels in the DSP rendered page to the DSP documentation itself.  Also, to hyperlink description template labels within the wiki page itself, e.g. creator to agent description.

ISSUE: Criteria should reflect that a property list constraint should be used once only within a description template. Guidance should be given to application profile creators on this issue, e.g. using the subject example where an application profile wants to require an LCSH term and have an option to add a free tag or a different vocabulary term.  Consider inclusion of this guidance on the current proposed guidelines for application profiles.  One option is to make the constraint human-readable only. Clarify with Mikael before progressing this.

RESOLVED: SWAP conforms

ACTION (Tom): Prepare final review document, to be finalised on a telecon pending revised SWAP document and list of corrections

ACTION (Julie as SWAP editor): Corrections to SWAP