All
(Now back from travels ;-)
You can find useful background information about the development of RDF
representations of ISBD, including the ISBD AP, in [1]. This article takes the
story up to the point where I raised the issue of what appeared to be missing
pieces in the DCAM/DCAP, specifically a stable version of DCAM/AP-specific
elements expressed in RDF and relationship to OWL approaches, at the Pittsburgh
meeting [2].
The ISBD/XML Study Group is assuming that the SES mappings will be based on
strings taken from low-level elements (e.g. Place of publication) concatenated
with the punctuation prescribed by ISBD. As Karen points out, this will not be
simple, because low-level elements can be repeated or missing, in which case the
puncutation pattern changes. Each area of ISBD prescribes the punctuation to be
used to concatenate elements and aggregated statements to generate the text
string for an instance of the area. Examples from area 3 (Publication,
production, distribution, etc., area) [ISBD enumeration]:
E. The date is preceded by a comma, space (, ).
G. The place of printing or manufacture, name of the printer or manufacturer and
date of printing or manufacture (for older monographic resources, when recorded
as a statement distinct from the publishing statement) are enclosed in one pair
of parentheses ( ( ) ). Within the parentheses the same punctuation is used as
in B, C and E.
There is also a set of punctuation patterns intended to cover the most
commonly-encountered situations. Examples from area 3:
. — Place of publication or production : name of publisher or producer, date
. — Place of publication or production ; place of publication or production :
name of publisher or producer, date (place of printing or manufacture ; place of
printing or manufacture : name of printer or manufacturer, date)
Algorithms and code for encoding ISBD aggregated statements/area strings exist.
It may be possible to develop decoding algorithms, which would be very useful
for parsing ISBD aggregated statements into strings which could be referenced as
things. This is the use case I mentioned in the last telecon [3].
ISBD punctuation is relevant to aggregated statements and SESs for MARC21, as
shown in the DCAM design pattern for Publication statement [4]. The ISBD
punctuation is embedded in the content (strings) of MARC21 records. This is no
longer (and in some quarters, never has been) considered good practice, but it
does lead to a simple SES encoding algorithm: concatenate the element strings
with a space ( ) delimiter in the order in which they appear. This is discussed
in [5].
I hope this helps. Some of the discussion has, for me, become quite tantalizing
[6]
btw, if anyone thinks it would be helpful to have access to the text of ISBD
(for research purposes such as this discussion), let me know. I may be able to
put a PDF copy on the wiki ...
Cheers
Gordon
[1]
http://leo.cilea.it/index.php/jlis/article/download/urn%3Anbn%3Ait%3Aunifi-3793/4408
[2] http://www.w3.org/2001/sw/wiki/JointMeeting2010
[3] http://wiki.dublincore.org/index.php/DCAM_Revision/TeleconReport-201206xx
[4]
http://wiki.dublincore.org/index.php/DCAM_Revision_Design_Patterns#Publication_statement
[5] http://managemetadata.com/blog/2012/05/20/taggregations/
[6] http://en.wikipedia.org/wiki/Tantalus
On 26 June 2012 at 14:04 Karen Coyle <[log in to unmask]> wrote:
> Thanks, Richard, for putting this into perspective.
>
>
> On 6/25/12 9:01 AM, Richard Urban wrote:
>
> >
> > I don't see how something like ISBD fits this definition of a datatype.
> > Is there a concept that better fits how we use ISBD? In the RDF datatype
> > documentation, "RDF provides for XML content as a literal value" (i.e. a
> > string which contains XML markup is it's own datatype defined as the
> > class "XMLLiteral"). (see
> > http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral) Importantly, this
> > datatype is disjoint from the value space of other XML datatypes (i.e.
> > dates, integers, etc.). It seems more appropriate to me that ISBD, like
> > XML, should be considered a markup language rather than a datatype.
>
> We'll need to wait for Jon and Gordon to weigh in, but I know that Jon
> has been at a conference and may be in the midst of lengthy travels.
> However, they have indeed created a number of SES's that are not
> "formal" datatypes in the sense you mean, both in RDA in RDF and ISBD in
> RDF. It's easier to see in the latter because each ISBD area is treated
> as an SES:
>
> http://metadataregistry.org/schemaprop/show/id/2135.html
>
> You can see how these appear in the Description Set Profile for ISBD:
>
> http://wiki.dublincore.org/index.php/DCAM_Revision_ISBD_DSP
>
> While these have been declared as SES's, I don't believe that they are
> actionable at the moment, in the sense that I don't know of a "mapping
> rule" for the declared SES's. Nor is it clear to me the relationship of
> the declared SES and the ISBD RDF properties for that area. So let's
> hope Jon's travels go well and he arrives refreshed ;-).
>
> kc
>
>
> >
> > I don't think DCAM would want to add a similar class of "ISBDLiteral"
> > (I'd prefer to leave that to someone developing an Application Profile
> > that needs to use ISBDLiterals), however we would need a new class in
> > addition to plain/typed that we currently have. Given the extent to
> > which "syntax encoding scheme" is already used within DC documentation
> > to refer to formal datatypes, it may be necessary to coin a new term
> > that denotes this class of more complex representation types. (it's a
> > bit of a minefield, so I'd like to think more on it before offering
> > suggestions).
> >
> > Richard J. Urban, Assistant Professor
> > School of Library and Information Studies
> > College of Communication and Information
> > Florida State University
> > [log in to unmask] <mailto:[log in to unmask]>
> > @musebrarian
> >
> > On Jun 24, 2012, at 4:22 PM, Karen Coyle wrote:
> >
> >> On 6/24/12 9:32 AM, Dan Matei wrote:
> >>
> >>>>> [URI(Beatles)] [URI(hasAppelation)]
> >>>>> [<name><nosort>The</nosort>Beatles</name>]
> >>>>
> >>>> What makes the value here an SES rather than a literal? In the case of
> >>>
> >>> Maybe a consuming application produces both a display form and a sort
> >>> key.
> >>
> >> Sorry, my question was pretty vague. I mean: how is a consuming
> >> program to know if this is a literal or an SES? In RDF there is a
> >> datatype, which appears to be quite liberal in application:
> >>
> >> "with an additional rdf:datatype="datatypeURI" attribute on the
> >> property element. Any RDF URI reference can be used in the attribute." [1]
> >>
> >> The DCAM SES is defined as:
> >>
> >> "syntax encoding scheme (http://www.w3.org/2000/01/rdf-schema#Datatype)
> >> A set of strings and an associated set of rules that describe a
> >> mapping between that set of strings and a set of resources. The
> >> mapping rules may define how the string is structured (for example
> >> DCMI Box) or they may simply enumerate all the strings and the
> >> corresponding resources (for example ISO 3166)." [2]
> >>
> >> So I'm wondering what constitutes a "mapping rule"? RDF does not
> >> appear to require a mapping rule, only a URI that defines (in some
> >> way) a datatype. Is the DCAM SES intended to be more strictly defined
> >> than the RDF:datatype? If not, is there a reason to define the SES if
> >> it is the same as the RDF:datatype?
> >>
> >> Shouldn't the examples here include the URI for the datatype/SES? Is
> >> that all that is required to make these valid DCAM?
> >>
> >>
> >> kc
> >> [1] http://www.w3.org/TR/REC-rdf-syntax/#section-Syntax-datatyped-literals
> >> [2] http://dublincore.org/documents/abstract-model/#sect-7
> >>>
> >>>> documentation in PDF enough to qualify as a "mapping rule"? Does a
> >>>> mapping rule have to be machine-actionable, e.g. in the case above would
> >>>> an XML schema be a mapping rule? And how will mapping rules for
> >>>> RDF-defined properties be expressed (since RDF, as I understand it, does
> >>>> not actually constrain in the sense that XML schema does).
> >>>
> >>> I don't know the canonical way of associating a SES with an RDF
> >>> statement. I would use (shamelessly) reification :-)
> >>>
> >>>>>
> >>>>> [URI(Dostoyevsky)] [URI(hasAppelation)]
> >>>> [<firstName>Fyodor</firstName><patronimic>Mikhaylovich</patronimic><surname>Dostoyevsky</surname>]
> >>>
> >>> Or, in this case, a useful form would also be:
> >>>
> >>> [URI(Dostoyevsky)] [URI(hasAppelation)] [Fyodor
> >>> Mikhaylovich<b>Dostoyevsky</b>]
> >>>
> >>> using HTML as SES.
> >>>
> >>> Dan
> >>>
> >>
> >> --
> >> Karen Coyle
> >> [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net
> >> ph: 1-510-540-7596
> >> m: 1-510-435-8234
> >> skype: kcoylenet
> >>
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
|