On 7/11/12 7:35 AM, [log in to unmask] wrote:
>>
>> So could those area SES's be used alone? Or are they the super-areas for
>> the aggregated statements that follow?
>
> Both. Usage is a bit tenuous: the only use case I know of for standalone areas
> is to display them in blocks (e.g. delimited by paragraph) rather than
> aggregated into a single statement representing the whole ISBD record (the
> catalogue card display). There was significant discussion in the ISBD Review
> Group about this use case, and its acceptance is further evidence of willingness
> to adopt good practice (in the context of the principals and goals of ISBD).
I, too, think that the separate properties (not just the areas) can be
defined as properties in RDF. I just don't think that they can be
considered as elements of an SES, mainly because of the ordering issues.
But I think this depends on how the SES is defined, and since it is
defined as a literal string... then it can be considered to maintain the
order. So when we have:
Title proper [General material designation] : other title information =
Parallel title : parallel other title information
The second ":" relates to the parallel title, even though there is
another ":" in the string. This is an example where order matters. If we
turn these into properties:
"isbd:titleProper="xxx";isbd:GMD="xxx";isbd:otherTitleInfo="xxx";isbd:parallelTitle="xxx";isbd:otherTitleInfo="xxx"
Somehow the SES mapping has to maintain the order, if I'm not mistaken,
or the "isbd:otherTitleInfo" doesn't get connected to the right title.
In the string the order is irrelevant because it is a simple literal
string, so there's no such thing as "order." Order matters when mapping
takes place.
So, the question is, is this a workable use of SES? In particular, is
the definition of SES such that maintenance of order can be a
requirement of the mapping rule? How would one indicate that order must
be maintained, or would one use rdf:list in the mapping rule?
I'm hoping that this is a question about the nature of SES, and not a
question about the nature of ISBD. That said, perhaps someone else can
articulate it better than I can.
kc
>
>>
>> In my approach, the areas would be properties that take literal strings
>> that are not treated as SES's. So I guess that's step above the area -> SES.
>
> I am not sure if there is a difference, and would welcome further explanation.
> As it is, the areas are properties in the ISBD namespace; for example [1]. The
> range is given as an SES [2]. I think this entails that the value of a triple
> using the property is a string (your approach) and is an instance of the SES. I
> guess that means the string should conform to the syntax pattern specified by
> the SES?
>
>>
>> I have to admit that I am unsure how the "parts" of an ISBD area can be
>> implemented as an SES, and would like to see an example. I know that the
>> ISBD AP relies heavily on the SES, but I don't understand where the SES
>> is defined in an actionable way that meets the ISBD rules for order,
>> etc. Perhaps that would be a good discussion for the next DCAM meeting.
>> Along with Richard Urban, I can see the strictly structured SES of
>> dates, and even the SES of DC BOX, but I can't make the leap to the
>> coded strings of ISBD. The difference that I see is that dates and BOX
>> are made up of (non-repeatable, if I am correct) parts that can be used
>> in various combinations and orders, while ISBD is made up of repeatable
>> parts whose order must be maintained in the creation order, and that
>> latter is not algorithmically predictable. So I guess I need to see the
>> rules that would govern such an SES.
>>
>> The examples that I gave in the notes were:
>>
>> London ; Chicago : Penguin, 2003
>> New York : Columbia University ; Boston : Computer Research Institute
>>
>> where the patterns are:
>>
>> place - place - publisher - date
>> place - publisher - place - publisher - date
>
> My crossed email covers some of this.
>
>>
>> and I also gave an example from MARC using names
>>
>> $a Black Foot, $c Chief, $d d. 1877 $c (Spirit)
>>
>> which is:
>>
>> name - title - date - title
>>
>> but here are some other examples:
>>
>> 100 10 |a Cayce, Edgar, |d 1877-1945 |c (Spirit)
>> 100 0_ |a Sixtus |b V, |c Pope, |d 1520-1590
>>
>> respectively:
>>
>> name - date - title
>> name - enumeration - title - date
>>
>> In these you can see that the relative order between the name, the date
>> and the title (spirit or pope) are not fixed, but depend on the context.
>
> Thank for bringing in the MARC example; this isn't just about ISBD! This
> situation doesn't occur in ISBD (I think/hope), as ISBD does not cover
> "headings" like this; they are seen as part of the relationships between the
> described resource and other entities, which are out of scope.
>
>>
>> (Note: the reason for this, of course, is that the library world has
>> given two different semantics to the same data element, but
>> unfortunately that occurs in various places in our data today.)
>>
>
> True. The semantics of MARC21 subfield c appear to differ depending on context,
> but some of this is explained by latent higher-level semantics; in this case,
> subfield c contains "Titles and other words associated with a name" and the
> higher context is data that can distinguish similar names in a useful way. The
> ordering of elements is governed by a mix of syntax and semantic (what type of
> name). The global library world has developed many sets of rules (not just two!)
> for governing these cases, and I guess that's a situation where DCAM/DCAP can be
> really helpful. It would be great to be able to express encoding (and decoding)
> of these strings in APs that focus on specific (cataloguing) rules acting on
> common element sets. For example, can VIAF be kind-of reverse-engineered so that
> it stores all the data EXCEPT the headings, which can be generated on the fly to
> conform to any regular display string (including display and browse formats
> which invert family and given names of persons).
>
> Cheers
>
> Gordon
>
> [1] http://metadataregistry.org/schemaprop/show/id/2142.html
> [2] http://metadataregistry.org/schemaprop/show/id/2141.html
>
>>
>> kc
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> ISBD is generally concerned only with transcriptions of strings found on the
>>> resource being described. The exception, newly introduced to the latest
>>> consolidated edition, is the use of controlled vocabularies in area 0
>>> (content
>>> and media type); these are treated as VESs in the AP. Whether ISBD continues
>>> this trend towards things rather than strings is a moot point. The primary
>>> purpose of ISBD is to create whole records that can be exchanged between
>>> national bibliographic agencies. The content of the record is intended to be
>>> descriptive (strings, not things). ISBD does not address relationships
>>> between
>>> the resource being described, or relationships with other entities such as
>>> agents, places, etc. (things). The next revision of ISBD will take place in
>>> around 3-4 years' time, and the ISBD Review Group is keen to hear arguments
>>> for
>>> best practice, linked data, etc. to inform that revision. It should be
>>> noted,
>>> however, that the I in ISBD needs to accommodate the needs of environments
>>> where
>>> little or no machine processing is available.
>>>
>>> Cheers
>>>
>>> Gordon
>>>
>>> [1]
>>> http://wiki.dublincore.org/index.php/DCAM_Revision_Design_Patterns#ISBD_DSP
>>>
>>
>> --
>> Karen Coyle
>> [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
|
