dc-provenance

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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!