On 8/15/12 1:20 PM, Thomas Baker wrote:
>
> The "Application Profile" part of the Singapore Framework [1] ends with "data
> formats" -- serializations of a Description Set Profile that is based on DCAM
> that, in turn, is based on RDF. In other words, the "end result" of applying
> the Singapore Framework is a model and serialization format for DCAM-conformant
> metadata.
Yes, but the application profile section includes "functional
requirements" "Domain model" and "usage guidelines." The document seems
to assume that functional requirements and usage guidelines are text (at
least I read it that way) and the domain model's definition includes:
"The domain model can be expressed using just text or using a more
formal approach such as UML."
Even UML is a document. So what I'm asking is whether we are considering
that the DSP should make reference to these documents? If not, then
would we consider providing a more formal best practice for the
documentation of these (important) aspects of the application profile?
In other words, the way I read the Singapore Framework document, the DSP
is only one part of an application profile. Are we considering the
entire application profile? or just the DSP? Because elements like usage
guidelines will NOT generally be encoded in the DSP, they will be beyond
its ken.
>
> In 2007, DCMI was emphasizing the "syntax guidelines" under development in
> the DCMI context -- generic guidelines about how to express metadata,
> DCAM-compliantly, in RDF/XML, HTML, and XML. The unspoken assumption, I would
> argue, was that the Singapore Framework was about designing DCAM-compliant
> metadata "from scratch".
And it seems that I would argue that the Singapore Framework goes beyond
DCAM -- it makes use of DCAM, and it supports DCAM, but I see nothing in
DCAM that requires usage guidance or even a conceptual community model.
The DSP provides the serialization, as you say, but serialization alone
seems reductive.
data can retain XML-like repeatable and ordered elements?
>
> If restrictions on repeatability and order are important, then expressing those
> limitations should be part of the DCAM vocabulary.
My point was a different one, I think, which is why I used XML as an
example. Let's use HTML because it's simple: I have an HTML document
that has:
<html>
<h1>A</h1>
<p>1</p>
<h1>B</h1>
<p>2</p>
<p>3</p>
</html>
The order of the elements is not defined in HTML, and order is not part
of the vocabulary (for the elements inside <html> here). However, that
document is not the same "bit" of information as:
<html>
<h1>B</h1>
<p>3</p>
<p>1</p>
<p>2</p>
<h1>A</h1>
</html>
Prior actually to creating the above documents, there is nothing in HTML
that would provide a "restriction on order" for those paragraphs,
although it does define restrictions on the order of opening and closing
of tags. I can create any number of different orders mixing paragraphs
and headings within an HTML document.
Do you think that DCAM should address this type of order within instance
documents? (Sorry, I don't know what else to call this.) If so, then it
will address the "ISBD problem" and the "MARC problem" and, even, the
"HTML problem."
Personally, I am reluctant to move into the variability of documents.
That HTML and RDF came from the same source (the mind of TBL), and one
is a document format and the other a data format, satisfies me to their
difference. This means, of course, that some information that has been
in document format in the past will translate poorly to the linked data
space. I accept that. But it seems that we still aren't clear about our
problem space if we are presuming to define DCAM to handle the document
format problem.
kc
Metadata modeled using
> DCAM, with such a vocabulary, and serialized with a syntax that would support
> those restrictions (such as XML), would be able to express such restrictions --
> even if the order would be lost in an export to RDF triples. Such a difference
> in expressivity between DCAM and RDF would justify the existence of a DCAM in
> the first place.
>
> Tom
>
> [1] http://dublincore.org/documents/2008/01/14/singapore-framework/singapore-framework.png
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
|