====== Participants ====== Tom, Corey, Michael, Daniel, Kai ====== Minutes ====== * [17:07] Topic: Relation of Provenance WG and Architecture Group * [17:08] == michaelp [~panzerm@132-174-21-112.ip.oclc.org] has joined #dcprov * [17:09] Tom: Important point is the notion of DS as something like a named graph in RDF. * [17:10] Tom: DCAM was meant to help from an engineering perspective in automation. * [17:11] Tom: New perspective might be to see it as an abstract model that helps people to understand RDF * [17:12] == charper1 [~Corey_Har@pool-108-54-183-195.nycmny.fios.verizon.net] has joined #dcprov * [17:14] Tom: DCAM hasn't been touches since its creation. * [17:15] Tom: Could be simplified and extended, fits with Provenance work * [17:15] Tom: Documents like Singaport Framework are well recognized, e.g. for educational purposes * [17:15] s/Singaport/Singapore * [17:16] Corey: 3 issues * [17:17] Corey: 1. Specific provenance metadata still needs an AP * [17:19] ... 2. Transform DCAM from technical framework to explanatory document * [17:19] 3. But we still need syntax for validation. DCAM as engineering doc provides that. * [17:24] Tom: Application profile provides properties and constraints informed by requirements. * [17:24] ... Are there requirements general enough in order to promote an AP for describing metadata provenance. To diverse? * [17:25] s/To/Too * [17:25] very interesting point * [17:25] @tbaker: we started gathering requirements, but they are bound to specific scenarios. Thas is why we decided to use DCAM to describe the provenance, because it is general enough * [17:25] ... Are there requirements to justify an specific AP? * [17:34] == charper1 has changed nick to chrpr * [17:35] Tom: Notation of AP is now more relaxed in DCMI. AP can more serve as an example. * [17:35] Tom: move toward Application Profiles as easily modifed examples of how to do something * [17:35] +1 * [17:35] ... Taking into account the heterogeneity of the web * [17:36] Michael: AP as best practice? * [17:36] ... or recipe? * [17:37] +1 to having the examples. People are lazy :D * [17:41] Kai: AP is not enough in the existing sense, because the best practice is not only about terms, it has to be about the model how the metadata and its provenance is represented * [17:41] DCAM re-write - clarify, and clarify relationship to RDF * [17:42] Kai: That's where we reached the limits of AP and got lost :-) * [17:51] Corey: DCAM is used on many ways, often more document centric, XML, JSON, ... whatever. * [17:52] Corey: Need to think before we revise it. It functions (and needs to function) as a bridge in both directions * [17:52] Corey: RDF and other models * [17:55] Provenance Deliverables: * [17:56] 1. Clarification of DCAM, Descriptn Sets as classes, identifiable, needs to be figured out together with architecture group * [17:56] 2. Usage guideline about the use of metalevel information to describe metadata (that's what we more or less have already) * [17:57] 3. New terms that are needed, probably a new namespace, but inside Dublin Core. Would have to be discussed publicly to ensure that these terms are well defined and meet common requirements * [17:57] 4. Create an AP that describes how DC terms and new terms are used to describe metadata * [17:58] Attempt to summarize, open for discussion... * [18:06] Tom: Vocabulary maintenance support is on the way, but not clear if we can use it in the nearer future * [18:07] Tom: Identification of terms that are needed can be done in parallel * [18:18] Question for Arch Forum: Provenance TG has a domain model: http://wiki.bib.uni-mannheim.de/dc-provenance/doku.php?id=domain_model, which is dependant on Description Set being addressible as a resource class. This extends DCAM. Is it desirable to incorporate that extension into DCAM itslef, or should that revised modeling be part of the Provenance Application Profile suite of documentation. * [18:33] Thanks again for all of this, and for agreeing to try & prompt some further discussion on the Architecture list!