Typo in the URL, this telco was on Jan 25th!

Participants

Kai, Tom, Corey, Michael (partially)

Minutes

[17:08] == kai [bc6e7eb1@gateway/web/freenode/ip.188.110.126.177] has joined #dcprov
[17:08] <kai> Topic: DCAM
[17:08] <kai> http://wiki.dublincore.org/index.php/DCAM_Revision_Scratchpad
[17:09] <kai> Very important to get terminology gap clear between RDF and DCAM
[17:09] <kai> Tom: What is DCAM?
[17:09] <kai> … a backend based on triples?
[17:10] <kai> … re. terminology: things have changed since 2005/2007
[17:12] <kai> … What makes DCAM interesting today?
[17:18] <kai> http://wiki.dublincore.org/index.php/DCAM_Revision_Tech
[17:18] == TomB [6c2d35e4@gateway/web/freenode/ip.108.45.53.228] has joined #dcprov
[17:18] <TomB> http://wiki.dublincore.org/index.php/DCAM_Revision_Tech
[17:18] <TomB> Kai: To summarize, agree with your points - get rid of terminology gap btw DCAM and RDF… (if a “statement” is not a triple)… unsure whether existing apps would suffer. Let's try changing terminology and see if there are complaints.
[17:19] <TomB> …Bridging terminology gap. Prefer to define DCAM in RDF. Ipossible to have a gap if one is totally based on the other.
[17:19] <TomB> …Have started. Not as easy as I thought.
[17:19] <TomB> …Get rid of Description?
[17:20] <TomB> …Keep Description as “set of statements” - what we would have to model with a graph (container). Description Set is not a graph any more, but a class…? Or could be a graph that contains other graphs.
[17:21] <TomB> ….Or get rid of Description - just have a “set of statements”… has a name, and that is the graph. Close to RDF, but maybe we like “Description” but with specific definition.
[17:22] == michaelp [~panzerm@132-174-21-187.ip.oclc.org] has joined #dcprov
[17:24] <TomB> Corey: Really important that we ground this in use cases emerging in communities that want to make use of this. One case, came up a few times at ALA last week:
[17:25] <TomB> …the Descriptions being drawn from record-like objects on LD cloud. Aggregations get disaggregated into triples stores to be reasembled into different description.
[17:25] <TomB> …If you have Description Set URIs, how do you track those thru lifecycle of metadata?
[17:26] <TomB> Kai: An implementation issue. My vision: model data in way that allows us to associate Provenance MD.
[17:26] <TomB> …App ensures that Provenance info is tightly coupled and does not get lost.
[17:27] <TomB> Corey: On BIBFRAME list, January 8 thread: catalogers thinking about provenance - W3C and DCMI ideas and how it relates to needs addressed now by MARC records.
[17:28] <TomB> http://listserv.loc.gov/listarch/bibframe.html
[17:29] <TomB> Michael: This aggreg/disaggreg thing: something that RDF will provide - named-graph association of triple is not lost when it is aggregated from the main graph.
[17:29] <@chrpr> Archives are open, and thread starts here:
[17:29] <@chrpr> http://listserv.loc.gov/cgi-bin/wa?A2=ind1201&L=bibframe&T=0&P=847
[17:29] <kai> I subscribed, it's open
[17:29] <TomB> …So even if you pull out triple, put in new aggregation, simply have a few named-graph URIs associated with that triple.
[17:30] <TomB> …Kai is correct: our Provenance model presents a way to do this.
[17:30] <TomB> Corey: Gordon doesn't mention Provenance group, but does mention DCAM discussion and efforts to align with RDF.
[17:36] <@chrpr> DCAM as slots for info that they might want to put in an MD “record”
[17:37] <@chrpr> What are bits of info to put there – blanks to fill in?
[17:37] <@chrpr> (I'm transcribing Tom's comments)
[17:38] <@chrpr> If you design MD according to DCAM & decide to map to triples later, that mapping's built in.
[17:38] <@chrpr> This is “interface to triples” concept.
[17:39] <@chrpr> My Q: Does this abstraction get harder as we more tightly bind DCAM to RDF concepts / model?
[17:40] <@chrpr> TomB: Example of DCAM valueString and valueSurrogate.
[17:42] <@chrpr> Kai__: Thinking of DCAM as equiv. to SKOS for MD. Helpful to think in these terms. Almost an extention to RDF.
[17:43] <TomB> Kai: One important thing for me: comparison btw DCAM and SKOS. Setting aside notion of graphs, etc… Equivalent of SKOS for metadata. SKOS as RDF vocabulary, etc. But valid to say it is also an Abstract Model that could be used by people who do not care about RDF.
[17:44] <@chrpr> Kai: Grounded in RDF so mapping is clear, but not forcing people to have to understand RDF.
[17:44] <TomB> Using SKOS, concepts can be identified using URIs, labeled with lexical strings in one or more natural languages, assigned notations (lexical codes), documented with various types of note, linked to other concepts and organized into informal hierarchies and association networks, aggregated into concept schemes, grouped into labeled and/or ordered collections, and mapped to concepts in other schemes.
[17:47] <TomB> Kai: “If you follow DCAM, whether you want it or not, you get RDF.”
[17:49] <TomB> Corey: “DCAM is designed to reconcile DC 1:1 principle with need to aggregate descriptions of more than one thing into data record”.
[17:49] <TomB> Kai: Let's avoid record.
[17:49] <TomB> Michael: Library community wants to get away from “records”.
[17:56] <kai> From DCAM: A description set is a set of one or more descriptions, each of which describes a single resource.
[17:57] <@chrpr> There is no property to “describe” the focus of a DCAM “record”
[17:57] <@chrpr> (Comment above is michaelp)
[17:57] <TomB> Michael: In DCAM, no property to describe “focus” of a Description Set - no presupposition that there is a focus.
[17:59] <kai> http://dublincore.org/documents/abstract-model/
[18:00] <TomB> Michael: Thrown off because in UML of abstract-model, Record is shown as an Aggregation, not an Instantiation.
[18:00] <TomB> …Make idea broader: this can be a named graph because we have guidelines how it maps.
[18:01] <TomB> …“Record” here is broader than a “record” in library world. “Specific way of expressing a Description Set in an Encoding Scheme”…
[18:01] <TomB> …rather, “Serialization” (since “encoding scheme” has a different meaning in DCAM).
[18:02] <michaelp> Sorry guys, have to run (sigh, the discussion has been really excellent) …
[18:02] <TomB> Corey: G-snap: reprsents what a G-box at certain point in time.
[18:02] <michaelp> Ill stay on IRC
[18:02] <TomB> ….Things important to that graph container - “in the context of a particular system”.
[18:02] <TomB> Thank you, Michael - that was great!
[18:03] <@chrpr> See “GraphConceptTerminology” on this page: http://www.w3.org/2011/prov/wiki/Using_graphs_to_model_Accounts
[18:03] <TomB> Kai: we do not have to do this on our own, just use RDF WG concepts.
[18:04] <TomB> Corey: On last DCAM call, two documents: high-level and technical. Maybe a third: includes specific instantiations in RDF - put graph serialization stuff there.
[18:05] <TomB> Kai: If we start to translate definitions, must be very careful.
[18:08] <@chrpr> TomB: Tying back to examples. At the time of DCAM's design, there were no thesauri that had URI's for terms. This has changed.
[18:09] <@chrpr> Is it still necessary to say that a subject heading named with a URI is a member of LCSH?
[18:12] <@chrpr> Kai: Is SKOS this same kind of “abstraction of” or “interface to” triples?
[18:13] <@chrpr> TomB / Kai: it could be used this way. Could be a document to teach people how to model a vocabulary that aligns w/ SKOS (and therefore RDF) without having to understand the background details of RDF.
[18:14] <@chrpr> Kai: Work through this, then ask the DCMI community how it works for them…
[18:15] <@chrpr> Constantly switching between: must use RDF and ok to not use RDF.
[18:15] <@chrpr> TomB: Really a false dichotomy
[18:16] <@chrpr> Kai: We have some time, as we can't really *finish* this until the new RDF is finished.
[18:18] <@chrpr> TomB: Trying to provide entre to these new concepts for a braoder audience. Will probably get good comments from the RDF crew.
[18:21] <@chrpr> http://www.redmine.org/
[18:28] <@chrpr> Just stumbled across this: Note on using Github api to export (open) issues because GitHub's “awful and meets none of the requirements for a bug tracker”:
[18:28] <@chrpr> because it's awful and meets none of the requirements for a bug tracker
[18:28] <@chrpr> http://www.lornajane.net/posts/2011/github-api-issues-list
[18:28] <@chrpr> https://gist.github.com/768875
[18:30] <@chrpr> TomB: “Record is a context for Provenance”
[18:36] <michaelp> D'accord, I would say: “Record/Description Set is subject for provenance.”
[18:37] <michaelp> Provenance MD describes a description set/“record”, so this entity is really needed.