[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 [~email@example.com] 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: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.
[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.