---------------------------------------------------------------------- From TBaker Wed May 3 15:40:35 2006 Date: Wed, 3 May 2006 13:15:02 +0100 Sender: A mailing list for the Dublin Core Metadata Initiative's Usage Board From: Andy Powell Subject: Domains and ranges To: DC-USAGE@JISCMAIL.AC.UK I've moved the DC domains and ranges document into the UB Wiki (and left a pointer from the old version in the Architecture Wiki) http://dublincore.org/usageboardwiki/PropertyDomainsAndRanges I've updated the definitions to use the agreed DCMIType style and to try and avoid any cyclical definitions. Note that the definition of Collection used here explicitly rules out a collection of ConceptualResources and is therefore narrower than the more general "Aggregation of Resources" definition that we agreed for the DCMIType list. Which is correct? I'm guessing that the original DCMIType definition "An aggregation of items" was also intended to rule out collections of concepts...? ---------------------------------------------------------------------- From TBaker Wed May 3 15:40:45 2006 Date: Wed, 3 May 2006 14:36:17 +0200 Sender: A mailing list for the Dublin Core Metadata Initiative's Usage Board From: Mikael Nilsson Subject: Re: Domains and ranges To: DC-USAGE@JISCMAIL.AC.UK On a related note, I've added some language about domains and ranges to the in-progress DC-RDF draft [1], as the RDF community will be most affected by this addition. The text currently says: "RDF supports using "domain" and "range" constraints on RDF properties, for limiting the kinds of resources that a property apply to, and the kinds of resources that may occur as values, respectively. This is not currently part of the DCMI Abstract Model. However, some properties may still come with such constraints, expressed formally in RDF schemas or informally in accompanying documentation. It is strongly recommended that metadata implementors be careful to follow such contraints when they exist, to ensure maximum interoperability. This is even more important in RDF than in other expressions of Dublin Core, as RDF adds a well-defined model for automatic processing of domain and range contraints." This is a first version of this text, so any comments from the UB would be very helpful at this point. [1] http://kmr.nada.kth.se/~mini/dc-rdf.html ---------------------------------------------------------------------- From TBaker Wed May 3 15:40:51 2006 Date: Wed, 3 May 2006 13:59:11 +0100 Sender: A mailing list for the Dublin Core Metadata Initiative's Usage Board From: Andy Powell Subject: Re: Domains and ranges To: DC-USAGE@JISCMAIL.AC.UK FWIW, my gut feeling is that we should acknowledge domains and ranges in the DCAM. We may provide machine-readable documentation about domains and ranges using RDFS, but we need to be clear that these constructs apply generally to DCAM properties. Having said that, I don't recall whether we reached any clear concensus at the Usage Board meeting about whether domains and ranges are a 'good thing'?? I need to go back to the notes of the meeting (yes, I know it was only 3 days ago, but my brain is completely frazzled!). Therefore, I'm not quite sure how we move any of this forward. ---------------------------------------------------------------------- From TBaker Wed May 3 17:44:08 2006 Date: Wed, 3 May 2006 14:52:38 +0100 Sender: A mailing list for the Dublin Core Metadata Initiative's Usage Board From: Alistair Miles Organization: CCLRC Rutherford Appleton Laboratory Subject: Re: Domains and ranges To: DC-USAGE@JISCMAIL.AC.UK Hi all, I've done a short comparison of the DCMI abstract model with the RDF concepts and abstract syntax, as part of a larger paper I'm trying to write on SKOS. It's online at: http://isegserv.itd.rl.ac.uk/public/skos/press/dc2006/rdfdcam.html I don't know if it bears directly on the domains and ranges discussion, and I haven't read Mikael's new draft yet, but I thought I'd post it now in case it's useful. Comments welcome. ---------------------------------------------------------------------- From TBaker Thu May 4 07:53:09 2006 Date: Wed, 3 May 2006 19:46:58 +0200 Sender: A mailing list for the Dublin Core Metadata Initiative's Usage Board From: Mikael Nilsson Subject: Re: Domains and ranges To: DC-USAGE@JISCMAIL.AC.UK I was about to answer this here, but then I thought that the discussion belongs better on dc-architecture... as that is where work on the draft happens. Would you mind reposting your message there, Alistair? ---------------------------------------------------------------------- From TBaker Thu May 25 12:24:48 2006 Date: Mon, 29 May 2006 21:07:49 +0200 Sender: DCMI Architecture Group From: Mikael Nilsson Subject: Public Comment on new Dublin Core metadata expression using RDF To: DC-ARCHITECTURE@JISCMAIL.AC.UK List-Help: , In March 2006, the DCMI Directorate awarded a contract to Mikael Nilsson (Royal Institute of Technology, Sweden) to draft a revision of the existing specification for expressing Dublin Core in RDF. The result of this work is a new working draft titled "Expressing Dublin Core metadata using the Resource Description Format (RDF)" http://dublincore.org/documents/2006/05/29/dc-rdf/ which will be available for comment by 17:00 EST on Tuesday, 30 May. As described in DCMI's "Procedure for approval of DCMI metadata terms and recommendations" [1], proposals subject to Public Comment are announced on DC-GENERAL and posted on the DCMI Web site for a period of at least four weeks. During that time, any interested member of the public may submit a comment, either publicly to a DCMI mailing list such as DC-ARCHITECTURE, non-publicly through DCMI Feedback (fbservice@dublincore.org), or directly to the issuer of the announcement. About the document ================= This document provides draft recommendations for expressing DC metadata using RDF, the Resource Description Framework. It does this by describing how the features of the DCMI Abstract Model [2] are represented using the RDF model. Subject to public review and discussion in the context of DCMI process, the May 2006 Working Draft is intended eventually to replace two legacy DCMI documents: * Expressing Simple Dublin Core in RDF/XML [3], a DCMI Recommendation from July 2002; * Expressing Qualified Dublin Core in RDF / XML [4], a DCMI Proposed Recommendation from May 2002. The document "Notes on DCMI specifications for Dublin Core metadata in RDF" [5] describes in more detail how this draft relates to the earlier specifications. DCMI is seeking comments from affected communities, and the content of any new DCMI Recommendation will depend on feedback received from these communities. The motivation for the new Working Draft was to provide an RDF expression that * provides a unified specification for Dublin Core in RDF * provides full support for the DCMI Abstract Model * provides good integration with other RDF metadata The Working Draft is based thoroughly on the DCMI Abstract Model, and includes a number of important changes to the previous specifications, such as: * Support for domains and ranges of properties * Support for multiple value string for a single value * Support for RDF datatypes * Deprecation of rdf:value (introduction of dcrdf:valueString) * Deprecation of RDF Containers * Deprecation of "poor man's language qualification" * Deprecation of "poor man's structured values" All of the above are issues that we hope to get feedback on during the public comment period. Support for domains and ranges ============================= The most significant change introduced by the May 2006 Working Draft is the addition of support for domains and ranges of properties in general, and of DCMI-defined properties in particular. The two legacy RDF expressions differ with regard to whether properties such as dc:creator and dc:date have values that are non-literal resources (e.g., a Person or a Date, seen as entities), or strings representing the resources (i.e., a value string). As part of the process of clarifying the RDF expression for Dublin Core metadata, it has become evident that DCMI would benefit from supplementing its English-language definitions with machine-understandable declarations of domains and ranges. As of the time of writing, the DCMI Usage Board is considering the assignment of formal domains and ranges which make explicit the meanings intended in the current natural-language definitions [6]. In accordance with the current approach, the DCMI Usage Board is considering the assignment of a range of "Agent" to dc:creator and dc:contributor, where "Agent" would be defined as "the class of all things that are a Person, Organization, or Service". Similarly, appropriate ranges would be specified for the other DCMI terms as well. Legacy RDF metadata ================== The assignment of any specific range would make one or another part of the legacy metadata appear invalid in the context of machine processing. Declaring "Agent" as the range of dc:creator would mean that inferencing applications would expect to treat the value of the dc:creator property as a non-literal entity. The legacy specifications did not properly address these ambiguities, with the result that an unknown amount of Dublin Core-based RDF data is inconsistent with the definitions of the Dublin Core properties. The new Working Draft is an attempt at providing a long-term solution to this issue, but as this has important consequences for the processing of legacy Dublin Core metadata in RDF, we hope that the affected communities will forward their comments on this matter. The Notes [5] provides more details on the matter. /Mikael [1] http://dublincore.org/usage/documents/approval/ [2] http://dublincore.org/documents/abstract-model/ [3] http://dublincore.org/documents/dcmes-xml/ [4] http://dublincore.org/documents/dcq-rdf-xml/ [5] http://dublincore.org/documents/2006/05/29/dc-rdf-notes/ [6] http://dublincore.org/usageboardwiki/PropertyDomainsAndRanges ---------------------------------------------------------------------- From tbaker Wed Jun 28 14:04:37 2006 Date: Wed, 28 Jun 2006 13:52:40 +0200 Sender: DCMI Architecture Group From: Mikael Nilsson Subject: New ranges only for the "terms" namespace? To: DC-ARCHITECTURE@JISCMAIL.AC.UK X-Archived: http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0606&L=dc-architecture&P=5526 Hi! There has been some discussion recently about the possibility of assigning the newly proposed ranges (see [1]) only to DCMI properties in the "http://purl.org/dc/terms/" namespace. I'd like to bring up the proposal here for further comments. Background ========= For some time now, the DCMI has discussed replicating the terms in the http://purl.org/dc/elements/1.1/ namespace ("1.1" below) into the http://purl.org/dc/terms/ namespace ("terms" below). The reason is that it would simplify for applications, as they would only have to reference a single namespace for all DCMI properties and encoding schemes (namely, the "terms" namespace). The "1.1" namespace would be retained for compatibility, and the relevant equivalences would be declared between the two. In parallel, the DCMI is considering adding domains and ranges to the DCMI properties. See [2] for some discussion. The "Literal" issue ================== Now, in the discussions about assigning ranges to DCMI properties, it has gradually become clear that current usage of DC in RDF is heavily dominated by literal string values, in conflict with the proposed ranges for the "1.1" terms. As some of you might have noticed, I have previously asked Swoogle for some statistics on the current use of DC in RDF. Here's an excerpt for the dc:creator property: Property Range Documents Triples dc:creator rdfs:Literal 234655 2477665 dc:creator wn:Person 2714 1138250 dc:creator cc:Agent 4090 6359 dc:creator foaf:Person 2281 5969 dc:creator foaf:Agent 1723 3234 We see that wordnet contributes a huge amount of triples from a single source. So, counting by documents instead, non-literal ranges account for maybe 1-2% of independent uses of dc:creator. Options ====== If the DCMI is going to introduce ranges for the DCMI properties and copy the "1.1" terms into the "terms" namespace, there are several options: 1) Assign the same ranges to both "1.1" properties and "terms" properties. As we can see from the above Swoogle data, non-Literal ranges will be problematic for most old data, in accordance with the discussion in [2]. 2) Assign the new ranges only to the properties in the "terms" namespace (including the copied properties from the "1.1" namespace). That would leave as valid any literal usage of the "1.1" properties, while allowing for the benefits of the new ranges in the "terms" namespace. Of course, literal usage of properties already in the "terms" namespace would still suffer, but that problem is at least one order of magnitude less important. 3) Do as in 2), but also assign a range of Literal to the "1.1" properties. The advantage of this approach is that the "1.1" properties will have well-defined ranges, making them easier to process. It would, however, invalidate the 1-2% non-literal uses of the "1.1" properties, and probably necessitate a change in the wording of the term definitions. Proposal ======= Based on the above situation, the current proposal is as follows: Given that DCMI: * Replicates the "1.1" terms into the "terms" namespace * Decides to introduce the proposed domains and ranges that DCMI: * Applies the new domains ranges to the properties in the "terms" namespace only * Leaves the definitions of the "1.1" properties as they are today. Some consequences ================ * Properties in the "1.1" namespace used with literal values are still valid * Properties in the "1.1" namespace used with non-literal values are still valid. * Properties in the "terms" namespace used with literal values no longer valid. This includes the terms copied from the "1.1" namespace. * Properties in the "terms" namespace used with non-literal values are still valid (if the value is of the right type). This includes the terms copied from the "1.1" namespace. * Replicated properties in the "terms" namespace can be made sub-properties of the original properties in the "1.1" namespace, for maximum interoperability. [1] http://dublincore.org/usageboardwiki/PropertyDomainsAndRanges [2] http://dublincore.org/documents/dc-rdf-notes/#sect-3 ---------------------------------------------------------------------- From tbaker@tbaker.de Fri Jun 30 14:12:28 2006 Date: Fri, 30 Jun 2006 14:12:28 +0200 From: Thomas Baker To: DCMI Usage Board Subject: [DC-USAGE] Full agenda for telecon today Agenda - Usage Board telecon 2006-06-30 Fri 1300 UTC (1500 Berlin, 0600 Seattle, 2200 Tokyo) See dialing instructions below For IRC, type "/join #UB" on the chat line at: -- irc://irc.ukoln.ac.uk/ or -- http://dev.ukoln.ac.uk/irc Participants: Tom, Akira, Joe, Andrew, Diane, Stuart Regrets: Andy [...snip...] 7. Replicating DCMES in the DCTERMS Namespace - and - Assigning Domains and Ranges to DCMI properties In Seattle, the Usage Board supported the idea that DCMI replicate the 15 DCMES elements in the DCTERMS namespace and suggested that DCMI not rush this decision -- rather, it was recommended that the Directorate consider the timeline, priorities, how to do an impact analysis, and resource requirements. In Seattle, the UB also agreed to progress the assignment of domains and ranges to DCMI terms [1], starting with approval of the class semantics (buy-in, public comment, F2F UB meeting, community consensus) and approval of the use of these classes as domains and ranges for DCMI terms (buy-in, public comment, F2F UB meeting, community consensus). Since then, I have discussed this with Mikael, who sees the following dependencies between the UB effort and the DCAM effort: 1. DCAM updates (clarification of Value Type, VES, SES, introduce notions of domains and ranges) 2. DC-TEXT, DC-XML and DC-RDF updated to reflect the above 3. Copy contents of "1.1" namespace to "terms" namespace 4. Introduce domains and ranges into "terms" namespace - Define semantics - Check if we want to reuse W3C classes - Declare classes - Apply to "terms" properties 5. Clarify whether encoding schemes are VESs or SESs 6. Approve DC-TEXT, DC-XML and DC-RDF as DCMI Recommendations Mikael has in the meantime kicked off discussion of a proposal on dc-architecture [2]. [1] http://dublincore.org/architecturewiki/DCPropertyDomainsRanges [2] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0606&L=dc-architecture&P=5526 ---------------------------------------------------------------------- From tbaker@tbaker.de Fri Jul 7 14:14:05 2006 Date: Fri, 7 Jul 2006 14:14:05 +0200 From: Thomas Baker To: DCMI Usage Board Subject: [DC-USAGE] Report 2006-06-30 telecon - actions for August Report - Usage Board telecon 2006-06-30 Fri 1300 UTC HTML: http://stage.dublincore.org/usageboard/log/.html/2006-06-30.ub-telecon-report.html Agenda: http://stage.dublincore.org/usageboard/log/.html/2006-06-30.ub-telecon-agenda.html Participants: Tom, Akira, Joe, Andrew, Diane, Stuart Regrets: Andy [...snip...] 7. Replicating DCMES in the DCTERMS Namespace - and - Assigning Domains and Ranges to DCMI properties In Seattle, the UB also agreed to progress the assignment of domains and ranges to DCMI terms [1], starting with approval of the class semantics (buy-in, public comment, F2F UB meeting, community consensus) and approval of the use of these classes as domains and ranges for DCMI terms (buy-in, public comment, F2F UB meeting, community consensus). Since then, I have discussed this with Mikael, who sees the following dependencies between the UB effort and the DCAM effort: 1. DCAM updates (clarification of Value Type, VES, SES, introduce notions of domains and ranges) 2. DC-TEXT, DC-XML and DC-RDF updated to reflect the above 3. Copy contents of "1.1" namespace to "terms" namespace 4. Introduce domains and ranges into "terms" namespace - Define semantics - Check if we want to reuse W3C classes - Declare classes - Apply to "terms" properties 5. Clarify whether encoding schemes are VESs or SESs 6. Approve DC-TEXT, DC-XML and DC-RDF as DCMI Recommendations Mikael has in the meantime kicked off discussion of a proposal on dc-architecture [2]. [1] http://dublincore.org/architecturewiki/DCPropertyDomainsRanges [2] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0606&L=dc-architecture&P=5526 ---------------------------------------------------------------------- From TBaker Fri Mar 10 16:26:31 2006 Date: Fri, 10 Mar 2006 14:51:06 -0000 Sender: DC Architecture RDF Taskforce From: Andy Powell Subject: DRAFT DC property domains and ranges To: DC-RDF-TASKFORCE@JISCMAIL.AC.UK Following the meeting this morning I have read thru and revised the draft "DC property domains and ranges" document in the Wiki http://dublincore.org/architecturewiki/DCPropertyDomainsRanges This document is now complete - I've added domains and ranges for everything. This has meant adding some new classes (for the properties that I ignored last time round!): Frequency AccrualMethod Policy InstructionalMethod ProvenenceStatement The major problem area (that I can see!) is with the dcterms:educationLevel property. I've assigned it a range that matches what I think was the intended use of the property and that fits with it being a sub-property of dcterms:audience but which is at odds with the wording of the definition :-( I think we need to revise the definition ASAP, to be something like: A class of entity for whom the resource is intended or useful, characterised in terms of the entity's location in or progression through an educational or training context. All, I'd appreciate comments on the draft as it now stands. ---------------------------------------------------------------------- From TBaker Fri Mar 10 16:26:32 2006 Date: Fri, 10 Mar 2006 16:08:10 +0100 Sender: DC Architecture RDF Taskforce From: Mikael Nilsson Subject: Re: DRAFT DC property domains and ranges Comments: To: Andy Powell To: DC-RDF-TASKFORCE@JISCMAIL.AC.UK Looking relatively good at a first glance. May I ask you to arrange the classes into class hierarchies? Especially the Manifestation/Resource hierarchy would be interesting to have explicit. Also, IMT does not really fit - it feels more like a VES (i.e. a subclass of a class in this list). But it's used in the property definition I suppose, so... ---------------------------------------------------------------------- From TBaker Sun Mar 12 16:17:08 2006 Date: Sun, 12 Mar 2006 14:05:01 +0000 Sender: A mailing list for the Dublin Core Metadata Initiative's Usage Board From: Pete Johnston Subject: Re: DCMI property domains and ranges To: DC-USAGE@JISCMAIL.AC.UK Thomas Baker wrote: > Andy's DCPropertyDomainsRanges draft [1] uses 30-40 > "possible classes" as proposed domains and ranges for all > DCMI properties. For the domains and ranges to be declared > machine-readably, these classes would presumably need to be > defined, approved, given URIs, and maintained. Giving them > URIs would involve either expanding the DCMI Type Vocabulary > or creating a new Vocabulary. Or they could be give "dcterms" URIs. Note that for some of the classes suggested for domain/ranges, there are already existing classes in the DCMI Type Vocabulary (collection, service) that fit the bill, so it would be redundant to create new classes for those two. I'm not necessarily using that as an argument for saying that it follows that they should all be given "dcmitype" URIs, just pointing out that those classes exist. > Creating a new Vocabulary > would involve revising the DCMI Namespace Policy. > > Giving them definitions would presumably also involve deciding > on a style for definitions that is consistent between the DCMI > Type Vocabulary and this new Domain-Range Vocabulary: Maybe worth noting that the "vocabulary encoding schemes" in the dcterms vocabulary are also classes, so ideally there should be consistency with the literals in those descriptions too. > -- Current DCMI Type Style: "A service is a system that provides..." > > -- DCMI Type Style, Renaud style: "A resource which is a system..." [2] > > -- Domain-Range Vocabulary style: "The class of all services..." [1] Strictly speaking the resource identified by the URI is a class and the third form is probably a more literal(!) reflection of that. The first two styles describe/define the class by describing/defining an instance of the class. I think that is quite widespread practice and I don't see it as a problem. But I agree that a consistent approach would be good. ---------------------------------------------------------------------- From TBaker Fri Mar 10 16:57:11 2006 Date: Fri, 10 Mar 2006 15:50:13 -0000 Sender: DC Architecture RDF Taskforce From: Andy Powell Subject: Re: DRAFT DC property domains and ranges Comments: To: Mikael Nilsson To: DC-RDF-TASKFORCE@JISCMAIL.AC.UK I've changed IMT to FileFormat - see what you think... I'll do the hierarchy thing... but not immediately! ---------------------------------------------------------------------- From TBaker Thu Mar 30 10:55:20 2006 Date: Thu, 30 Mar 2006 10:35:12 +0200 Sender: A mailing list for the Dublin Core Metadata Initiative's Usage Board From: Thomas Baker Subject: Report 2006-03-23 telecon To: DC-USAGE@JISCMAIL.AC.UK Agenda: http://stage.dublincore.org/usageboard/log/.html/2006-03-23.ub-telecon-agenda.txt.html This report: http://stage.dublincore.org/usageboard/log/.html/2006-03-23.ub-telecon-report.txt.html Usage Board telecon - report 2006-03-23 Thu 1400 UTC Regrets: Andrew -- DCMI property domains and ranges (Andy) http://dublincore.org/architecturewiki/DCPropertyDomainsRanges [...snip...] 2006-03-13. Andy has been working on this and proposes that we put it on the agenda for Seattle. Andy has assigned domains and ranges to all DCMI terms. We want a reasonable set of domains and ranges. In Seattle, our goal should be to agree this is a reasonable thing to do. We should weigh whether we want to do this at all -- what are the implications of doing it. One main issue is "educationalLevel". Diane: in looking through possible classes, I see that 3 out of 4 use FRBR -- I was trying to see where these were assigned. Andy: I thought all these classes were used somewhere but need to check. Some may only be used in definitions of other classes - so not directly assigned. For example, "work" is there in order to define "manifestation". Need to double-check which classes are actually used. -- check to make sure there are no "hanging classes" that do not get used anywhere. Diane: Problems arise with FRBR expressions: often, "manifestations" relate to expressions, not necessarily to works. Eg, translation as an expression. Manifestation of that translation skips a level in terms of FRBR. Difficult to always distinguish btw manifestation and an Item; things can be both Manifestation and Item in the digital context. Most work on FRBR has come from a library context. Joe: in the archival community, everything is a "copy". Resources -- digital resources and physical resources -- but we do not necessarily need to talk about items and manifestations. What are the consequences about being explicit about domains and ranges? Diane: good to discuss but agree with Tom -- one step at a time. Andy: the minimal aim - if we cannot agree on actual classes - is to decide where this document is going. Second issue: style of definitions. Tom: we should decide on a style: -- Current DCMI Type Style: "A service is a system that provides..." -- DCMI Type Style, Renaud style: "A resource which is a system..." [2] -- Domain-Range Vocabulary style: "The class of all services..." [1] Andy: I'm not convinced these are "just" stylistic changes. Example: saying that a "service" is a "system" is not defining the class. We are just correcting the definition - not changing how the definition is interpreted; making explicit what is currently implicit in a definition. RESOLVED This document now belongs to UB. ACTION Andy Consider removing the FRBR-related classes. ACTION: Tom - do two or three of the type vocabulary in the "domain/range vocabulary" style - in Seattle, we look at three and make a decision. ---------------------------------------------------------------------- From tbaker@tbaker.de Fri Jun 23 11:40:53 2006 Date: Fri, 23 Jun 2006 11:40:53 +0200 From: Thomas Baker Subject: Re: Range proposal on dc-architecture FYI - I have reworked the notes from the Seattle UB meeting for clarity. Here are the parts summarizing discussion about replicating DCMES in TERMS and about domains and ranges. ---------------------------------------------------------------------- Agenda Item #3: Replicating DCMES in the DCTERMS Namespace The Usage Board supports the idea that DCMI replicate the 15 DCMES elements in the DCTERMS namespace. Communities need to be convinced that this is a good idea. We need to have data and feedback from implementers about potential impact -- for example, from commercial users and from aggregators such as NSDL. We should not rush this decision. The Directorate should consider the timeline, priorities, how to do an impact analysis, and resource requirements. ---------------------------------------------------------------------- Agenda Item #4: DCMI Property Domains and Ranges The question discussed: Do we want to assign domains and ranges to DCMI properties? Arguments for: -- semantics of the DC properties are more specific and explicit -- support for Semantic Web inferencing Arguments against: -- DC is fuzzy, has traditionally been quite fuzzy, and we may or may not want to lose that fuzziness If we decide to do this, should DCMI create the domain/range classes from scratch? Or should we use existing classes, adding where necessary? Work to date has been on creating roughly thirty classes (terms) in a domains and ranges vocabulary [1]. The alternative would be to re-use existing classes (i.e., not create new URIs). We note the existence of several other vocabularies that might be defined and identified with URIs: -- DCMI Abstract Model entities -- Terms for describing Application Profiles -- Terms for describing DCMI terms (e.g., Status) -- A controlled vocabulary of types of Status -- The domains and ranges vocabulary These vocabularies should use terms from RDF/RDFS when appropriate but coin DCMI properties when necessary. The way forward: Stage 1 1. Approve the semantics of the classes [buy in, public comment, f2f UB meeting, community consensus] 2. Approve the application of these classes as domains and ranges for DCMI terms [buy in, public comment, f2f UB meeting, community consensus] Stage 2 3. Declare classes used as domains and ranges. 4. Declare DCMI properties (formally) using domains and ranges. Stage 3 5. Consider implications for UB review of APs. This may change the kinds of documentation we request from communities -- e.g., with regard to refinement of domains and ranges of properties in APs and testing for compliance with DCMI domains and ranges. AGREED: We want to start the process of the stages 1-3 above. ACTION: Tom to deliver a work plan for how to achieve this. NOTED: It was argued that clarification of how to implement the agent elements is on the critical path to assigning domains and ranges to DCMI properties. NOTED: In a general sense, the revisions of DC-RDF and DC-XML are addressing the above concern. [1] http://dublincore.org/architecturewiki/DCPropertyDomainsRanges