Tom, Corey, Michael, Daniel, Kai

• [17:07] <kai_> Topic: Relation of Provenance WG and Architecture Group
• [17:08] == michaelp [~panzerm@132-174-21-112.ip.oclc.org] has joined #dcprov
• [17:09] <kai_> Tom: Important point is the notion of DS as something like a named graph in RDF.
• [17:10] <kai_> Tom: DCAM was meant to help from an engineering perspective in automation.
• [17:11] <kai_> 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] <kai_> Tom: DCAM hasn't been touches since its creation.
• [17:15] <kai_> Tom: Could be simplified and extended, fits with Provenance work
• [17:15] <kai_> Tom: Documents like Singaport Framework are well recognized, e.g. for educational purposes
• [17:15] <michaelp> s/Singaport/Singapore
• [17:16] <kai_> Corey: 3 issues
• [17:17] <michaelp> Corey: 1. Specific provenance metadata still needs an AP
• [17:19] <michaelp> … 2. Transform DCAM from technical framework to explanatory document
• [17:19] <michaelp> 3. But we still need syntax for validation. DCAM as engineering doc provides that.
• [17:24] <michaelp> Tom: Application profile provides properties and constraints informed by requirements.
• [17:24] <michaelp> … Are there requirements general enough in order to promote an AP for describing metadata provenance. To diverse?
• [17:25] <michaelp> s/To/Too
• [17:25] <kai_> very interesting point
• [17:25] <DGarijo> @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] <michaelp> … Are there requirements to justify an specific AP?
• [17:34] == charper1 has changed nick to chrpr
• [17:35] <michaelp> Tom: Notation of AP is now more relaxed in DCMI. AP can more serve as an example.
• [17:35] <chrpr> Tom: move toward Application Profiles as easily modifed examples of how to do something
• [17:35] <chrpr> +1
• [17:35] <michaelp> … Taking into account the heterogeneity of the web
• [17:36] <michaelp> Michael: AP as best practice?
• [17:36] <michaelp> … or recipe?
• [17:37] <DGarijo> +1 to having the examples. People are lazy :D
• [17:41] <kai_> 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] <chrpr> DCAM re-write - clarify, and clarify relationship to RDF
• [17:42] <kai_> Kai: That's where we reached the limits of AP and got lost
• [17:51] <kai_> Corey: DCAM is used on many ways, often more document centric, XML, JSON, … whatever.
• [17:52] <kai_> Corey: Need to think before we revise it. It functions (and needs to function) as a bridge in both directions
• [17:52] <kai_> Corey: RDF and other models
• [17:55] <kai_> Provenance Deliverables:
• [17:56] <kai_> 1. Clarification of DCAM, Descriptn Sets as classes, identifiable, needs to be figured out together with architecture group
• [17:56] <kai_> 2. Usage guideline about the use of metalevel information to describe metadata (that's what we more or less have already)
• [17:57] <kai_> 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] <kai_> 4. Create an AP that describes how DC terms and new terms are used to describe metadata
• [17:58] <kai_> Attempt to summarize, open for discussion…
• [18:06] <kai_> Tom: Vocabulary maintenance support is on the way, but not clear if we can use it in the nearer future
• [18:07] <kai_> Tom: Identification of terms that are needed can be done in parallel
• [18:18] <chrpr> 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] <chrpr> Thanks again for all of this, and for agreeing to try & prompt some further discussion on the Architecture list!