Hi everyone,
Sorry I won't be able to join the call today, so I thought I'd send a few comments to the list.
Tom, I believe "slots" are a new introduction to the DCAM (at least from my reading), but it does seem to introduce the possibility of confusion with how "slots" are used in frame-based languages (http://en.wikipedia.org/wiki/Frame_language). Is the concept of slots we are introducing here equivalent to those kinds of slots or are we introducing a DCAM specific concept? If the latter, it may help to spell out what the features of these slots are (beyond properties/values).
> I'm not sure whether the mixing of
> references to syntax ("slots", "Value URI") and semantics ("Thing Described")
> in this draft is a bug -- or a feature.
So "slots" are a syntactical concept? If we are basing DCAM on the RDF model, it seems that "semantics" also incorporates the abstract construction of grammatical features like "statements." I would therefore expect "slots" to be at that abstract level.
Following that thread, are DCAM Statements still just be property/value slots, or are they now more like a triple, with a (for lack of a better term) slot that holds a URI that refers to the Thing Described? An important part of preserving intuitive sense of colloquial records is that such URIs are optional. I think this is equivalent to RDFs concept of blank nodes, but I don't think that connection has been explicitly drawn in DCAM. (Kai?) If DCAM is standing slightly apart from RDF to accomodate colloquial XML records[1] , does our sense of statements/described resource URIs align with this concept? The Linked Data community is discouraging blank nodes, so we could imagine a DCAM that also requires URIs for all Things. (I suspect that this is not what we want to do, but putting it out there for discussion). (see "In order to provide compatibility with Semantic Web and Linked Data applications, however, DCAM is fully aligned with the Model and Abstract Syntax of RDF"). It also seems that Linked Data's requirement to including Thing URIs is the kind of constraints that we might be modeling at the level of DCAM and might afford some useful real-world examples of how it's done. ( how is this similar/different to the kinds of constraints we need to express at the DSP level?)
Lastly, since we are also trying to work backwards from XML, we frequently using the term "records" in discussing DCAM. i.e.
> The Dublin Core Abstract Model (DCAM) provides a language for representing
> the structure of specific Metadata Records -- put more abstractly, to
> specify a Description Set Profile -- in a form that is independent of
> particular Concrete Encoding Technologies such as XML Schema, RDF/XML,
> RelaxNG, relational databases, Schematron, or JSON.
I don't think DCAM is after Description Set Profiles directly, rather it models our intuitive sense of "records" as an abstract "Description Set." (which then enables us to specify a DSP). I think it does pretty well at this, but I'm curious if there are objections to "Description Sets" that should go into our gap analysis. Jon et al. are there things about the kinds of records you work with that don't fit the current DCAM model?
Richard J. Urban, Visiting Professor
School of Library and Information Studies
College of Communication and Information
Florida State University
[log in to unmask]
@musebrarian
[1] Sperberg-McQueen, C.M. and Miller, E. On mapping from colloquial XML to RDF using XSLT. Proceedings of Extreme Markup Languages 2004. http://conferences.idealliance.org/extreme/html/2004/Sperberg-McQueen01/EML2004Sperberg-McQueen01.html
On Feb 14, 2012, at 6:04 PM, Thomas Baker wrote:
> On Tue, Feb 14, 2012 at 05:25:17PM -0500, Tom Baker wrote:
>> And there was some support for the idea that a clear "punchline" for
>> DCAM, along the lines of the one-liner summarizing SKOS in plain language,
>> would be helpful.
>
> A bit longer than the one-liner for SKOS, but here's my stab at
> a "general message" for DCAM:
>
> Seen as data artifacts, Metadata Records consist of slots holding
> information items in a defined structure. A Metadata Record may describe a
> single Thing of interest (such as a Book) or a cluster of closely related
> Things (such as a Book and its Author). More abstractly, a Metadata Record
> may be seen as a Description Set encompassing just one Description (i.e.,
> about the Book) or multiple Descriptions (about both the Book and the
> Author).
>
> A Description consists of one or more Statements about the Thing Described
> (e.g., stating the Name and Birthdate of an Author). The Thing Described
> by a Description may be identified using a URI. A Statement about the
> Thing Described has one slot for an Attribute (Property) and one slot for a
> Value. Attribute slots are filled with names of attributes (properties);
> in DCAM, attributes are "named" using URIs. Value slots are filled with
> Value Strings, URIs, or blank Value Placeholders. A Value String may be
> stated as belonging to a named set of strings (known as a Syntax Encoding
> Scheme). A Value URI may be stated as belonging to a named set of URIs
> (known as a Vocabulary Encoding Scheme). In practice, Statements may be
> viewed in the context of Statement Sets. Statement Sets may follow common
> patterns.
>
> The Dublin Core Abstract Model (DCAM) provides a language for representing
> the structure of specific Metadata Records -- put more abstractly, to
> specify a Description Set Profile -- in a form that is independent of
> particular Concrete Encoding Technologies such as XML Schema, RDF/XML,
> RelaxNG, relational databases, Schematron, or JSON.
>
> In order to provide compatibility with Semantic Web and Linked Data
> applications, however, DCAM is fully aligned with the Model and Abstract
> Syntax of RDF. (Note that the RDF abstract model is the basis for -- thus
> distinct from -- concrete RDF encoding technologies such as RDF/XML,
> N-Triples, and Turtle.) Knowledge of RDF is not a prerequisite for
> understanding DCAM on an informal level.
>
> DCAM provides a language for expressing common patterns of Statements --
> patterns that may be partially or fully encoded using specific Concrete
> Encoding Technologies. Indeed, some readers may find the example patterns
> used in designing DCAM more accessible and useful, as models and templates
> for implementation, than the formal specification of DCAM itself.
>
> Details aside, this text illustrates the sort of high-level description I think
> we would need to have as an explanation both to our intended audience -- and to
> guide ourselves in the design phase. I'm not sure whether the mixing of
> references to syntax ("slots", "Value URI") and semantics ("Thing Described")
> in this draft is a bug -- or a feature. I also wonder how DCAM can close the
> gap to expressing the constraints of real application profiles without
> introducing DC-DSP-like notions such as "templates" and "constraints" [1].
>
> For discussion...
>
> Tom
>
> [1] http://dublincore.org/documents/dc-dsp/
>
> --
> Tom Baker <[log in to unmask]>
>
