Aim: to better understand how the UB "approves" APs and what the consequences of that are in terms of "term" and "AP" maintenance, namespaces, etc. At this stage we are not ready to actually approve the DCCDAP because no public comment period has been undertaken and there are some outstanding issues with the AP itself.
This may result in changes being made to the CEN AP Guidelines document (e.g. making assignment of URI to terms mandatory). May also result in changes to other documents: Term decision tree, etc.
Medium-term aim is for a suite of documents that describe and document APs in ways that are useful to people creating them.
Editorial note: In AP Summary "Property" should be "Qualified Name" (for consistency with the full AP document).
Issue: Discussion about use of dcmitype:Collection as a vocabulary encoding scheme. Issue with the AM -- all VES are classes but should all classes be treated as VESs? Could consider adding notion of "range" to the AM, but would need something like "applicationProfileRange" for use in APs. Work of the DC/RDF Taskforce is beginning to think about assigning domains and ranges to DC properties, so likely to have to add notion of "domain" and "range" to the AM at some point. Need to think about what impact this has on the model for APs.
Issue: AP creators are not necessarily sophisticated enough to deal with RDFS/OWL and the concepts in the AM. Need human-readable documentation (e.g. summary tables along the lines used in the draft DCCDAP) that forces AP developers down the right road without confusing them.
Issue: Need to develop model of APs, based on the work done for the DCCDAP, including assigning URIs to all the concepts used in the model ("obligation", "mandatory", "element", "element refinement", etc.).
Issue: what is "defined by" for?
Issue: what does the UB want to say about APs -- e.g. what statuses are we intending to assign?
Issue: what are APs for? Documenting current practice? Declaring future practice? Should an AP be able to document usage that doesn't conform to the AM?
We agreed the following statements:
Issue: there is a potential problem with the use of both an element and one or more of its refinements in a DCAP (e.g. the use of both relation and references in the DCCDAP) because inferences made on the use of the refinement may not be compatible with the DCAP defined usage of the element. Suggest considering use of new refinements (e.g. "relatedCollection") to get round this problem. This issue needs to be covered in future guidance for creating new APs.
Action: Tom to revise the CEN Guidelines in line with the documentary approach used in the draft DCCDAP.
Agreed: in AP drafts, example.org will be used for terms that do not yet have a real URI.
New properties and encoding schemes that arise from DCMI "strategic" activities and that conform to the AM but do not yet have a URI will be added to the DCTERMS namespace.
So new terms in draft APs either have real URIs already assigned OR they have example.org URIs, which is an indication that the term needs to be assigned a URI in the DCTERMS namespace.
Action: AndyP to review the details in the decision tree about how terms should be declared.
Agreed: Draft APs that contain new terms must be accompanied by appropriate documentation for the new term.
Issue: What is "appropriate documentation" in the context of new terms in draft APs?
Agreed: Human-readable and/or machine-readable statements about the type of all terms used in APs (e.g. "This is an Element as defined in the DCAM") should be made available at the term URI.
Agreed: When an activity is identified as being strategic, DCMI needs to ensure ongoing UB engagement ASAP.
Action: Need to revise the criteria for evaluating new terms in the process document - Stuart, Diane.
Issue: Are APs intended to be used to validate instance metadata? I.e. is some instance metadata that includes additional terms non-conformant with an AP? This should be discussed in the CEN Guidelines.
Action: change comment for Software to provide list of examples "C source file, MS-Windows .exe executable, Perl script, etc."
Action: Leave comment for Sound unchanged.
Action: Change "For example --" to "Examples include:" throughout.
Action: Terms to be arranged alphabetically.
Action: All references to other terms in DCMIType should just use the term label without quotes (e.g. Moving Image).
All actions on Stuart and Diane.
Note: Need to add proposed change to dcterms:URI to change seeAlso link to new URI spec.
Agreed: Use "The spatial or temporal topic of the resource, or the jurisdiction under which the resource is relevant" as definition of Coverage. Change comment to something like "Spatial topic may be a named place...".
Agreed: Use "The medium, Internet Media Type or extent of the resource" as definition of Format. Need to revise the comment to explain these three parts. Change comment to include "Format may be used to select the software, hardware, or other equipment needed to display or operate the resource".
Note: Need to change final sentence of Type comment in line with Format definition.
Agreed: Change definition of Creator to "An entity primarily responsible for making the resource" and change definition of Contributor to "An entity responsible for making contributions to the resource".
Action: Remove use of "Resource" prefix from Type and Identifier labels.
Action: Andy to make changes above.
Action: Diane to write up short document giving the rational for these changes.
Actions to be undertaken prior to next teleconference.
Need to define set of DC classes (an ontology) for use as domains and ranges, but map to equivalent existing classes in other namespaces as appropriate.
Need to think about how to iterate the development of our ontology -- and how to engage with community. Possibly declare in parallel with other DCMI RDFS declarations for the time being.
This activity fits better within UB remit than within DC Architecture.
Action: DC RDF taskforce to continue developing draft document of domains and ranges -- to be brought back to UB when reasonable draft is ready for consideration of how to handover activity to the UB.
End of day 1
Agreed: accept the change to the comment for dc:date as recommended by the WG.
Action: Andy to add change to list of other changes to DCMES terms.
Add "Editorial Changes" section to the end of each of these documents, noting why these changes have happened.
Remove un-used references.
Tidy up hyphenated words (as per Tom's comments).
Issue: should these documents still have "Recommended status"?
Change titles (and other text) to use "DCMI DCSV: A syntax for representing simple structured data in a text string".
Agreed with Tom's points 2, 3, 4, 5, 6, 7, 8 and 9.
Note: need to add definition of "structured value string" to terminology section.
Issue: Note this also requires change to the abstract model terminology.
Spelling of "hierarchical".
Make changes as per Ann's comments.
Make changes as per Pete's comments.
Action: Andy and Andrew to make changes above and send to list.
Agreed: Need to change status of these documents to "Rescinded Recommendation" with note about historical context and justification.
Agreed: change status of Period, Point and Box to "Conforming". VOTE: 6 in favor, none against, none abstain.
Action: Tom to write up decision text (for the change to the terms above) and approve on the list.
Agreed: Fix the redirects to the current Recommendations on the Web site. Put current proposed changes as date-stamped "Proposed Recommendations". Put new proposed changes as date-stamped "Proposed Rescinded Recommendations" and submit to Directorate for comment period.
Action: Tom to clarify process for doing this with Directorate.
Issue: Frequency of updates to the DCMI Web site is sometimes problematic.
Action: Tom to raise this with the Directorate.
Issue: what should be served at term URIs and namespace URIs.
Agreed: Emerging best practice is to use content negotiation to serve both text/html and application/rdf+xml. Should use an HTTP 303 reposnse to redirect from term URI to representation. Do this at both the term URIs and the namespace URI.
Action: Andy to write up requirement for what needs to happen on the DCMI Web server to achieve this for current DCMI terms/namespaces and send to list for forwarding to Web team.
Action: Tom to liaise with Rebecca about what DCMI is doing.
For the text/html representation of a DCMI term, the HTTP 303 redirect should go to the anchor for that term in http://dublincore.org/documents/dcmi-terms/.
For the application/rdf+xml representation of a DCMI term, serve the RDFS for the whole namespace initially -- but could have a discussion on DC Architecture about whether it is better to only serve RDFS for the individual terms.
Action: Tom/Diane to undertake other ongoing actions from pages 8 and 9 of the packet.
Action: Pete to update "Element refinement in DC Metadata" Recommended Resource in order to use correct MARC relator URI. (No comment period required).
Issue: what assertions do we want to make about MARC Relator Terms?
Action: Tom to do both on open-ended basis as human-readable document.
Agreed: Use a "DCMI list of trusted RDFS data sources" as mechanism for indicating endorsement of whole vocabularies? It may be that in the future we choose to drive the DCMI registry from this list and that therefore the appearance of something in the DCMI registry implies endorsement by DCMI.
Agreed: The initial list is:
Agreed: Addition of new trusted RDFS data sources is driven by the development of APs in WGs.
Part I
Put current 3.2 (Conforming) to 3.1. Move 3.1 (Recommended) to 3.2 and change meaning in line with decisions in Washington (i.e. conforming and no overlap).
Issue: what statuses are needed in the process document?
Definition of Endorsed needs some work -- it is about "relationship" assertions between terms, not about the terms themselves.
Part II
Break out parts about evaluating individual terms into separate citable document.
Break out vocabulary of statuses into separate citable document.
Break out parts about UB makeup, processes (I) and changes to processes (III) into separate citable document.
Consider move to "step-by-step" approach to documenting process (as per document below) -- at least at summary level.
Note: "Procedure for approval of DCMI Metadata Terms and Recommendations" at http://dublincore.org/usage/documents/approval/ will need to be updated to focus on APs rather than individual terms.
Action: Diane and Stuart to move process document forward.
Guidelines for some new elements Agreed to proposals with a couple of minor editorial changes.
Vocabulary vs. Syntax Encoding Schemes
Move action on Pete and Andy to write position paper about Vocabulary and Syntax encoding schemes to DC RDF Taskforce.
Endorsement of external encoding schemes
To be conformant with the DCAM
Action: Andy to add these criteria to the "decision tree".
Action: Andy/Tom to undertake process to assign status to decision tree document.