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/