Participants

Tom, Corey, Michael, Daniel, Kai

Minutes

[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!