On Wed, Apr 11, 2012 at 07:36:57AM +0200, Karen Coyle wrote:
> An example of a publication statement, as it appears today, is:
>
> New York, Bowker, 1987
>
> coded as:
>
> place of publication: New York
> publisher: Bowker
> date: 1987
>
> The order is fixed, and any of the parts can be repeated, although
> again with a fixed order. In library data today, repeated elements
> \= repeated coding:
>
> place of publication: London, New York
> publisher: Penguin, Bowker
> date: 1987
As I see it, a Syntax Encoding Scheme is a specification that provides a
context for interpreting literal values. An SES can be specified either by
listing all of the possible literals (e.g., a comprehensive list of language
tags) or by describing rules by which literals can be generated (e.g., a
specification describing the YYYY-MM-DD pattern instead of providing a long
list of actual dates, or DCMI Box Encoding Scheme [1] instead of an infinite
list of possible boxes).
In the case of Publication Statement [2], I take the literal in question to be:
"New York, Bowker, 1987"
which conforms to the "simple"-variant specification provided by Gordon:
[Place of publication, production and/or distribution statement] : [Name of
publisher, producer and/or distributor statement], [Date of publication,
production and/or distribution]
In other words, I see the literal above as being contextualized by a SES
which specifies the pattern above. In Turtle, the literal would be
represented along with a URI for that SES specification:
"New York, Bowker, 1987"^^<http://example.org/publication-statement-SES>
On the other hand, I would take the "coding" you provide:
place of publication: New York
publisher: Bowker
date: 1987
as something that would be used on the back-end to manage the contents of --
and to generate -- the literal "New York, Bowker, 1987".
If that is the case, then it doesn't matter whether that back-end
representation is coded as simple plain-text attribute-value pairs (taking the
example above _literally_) or in a relational database or whatever.
This is, in fact, a good example of what I think of -- conceptually -- as a
Description Set Profile. The template for the SES would have slots for:
Place of publication
Place of production
Distribution statement
Name of publisher
Name of producer
Distributor statement
Date of publication
Date of production
Date of distribution
...possibly specified independently of the Publication Statement SES itself.
In other words, the _contents_ of "New York, Bowker, 1987" would be held in a
backend database, the structure of which could be seen as conforming to a
Description Set Profile. Ideally, then, the Description Set Profile would
specify all the necessary orders and cardinalities. The SES specification,
then, would explain how to serialize that DSP in the punctuation-separated
syntax required by ISBD.
Tom
[1] http://dublincore.org/documents/dcmi-box/
[2] http://wiki.dublincore.org/index.php/DCAM_Revision_High_Level_Example_Publication_Statement
--
Tom Baker <[log in to unmask]>
|