Print

Print


Is there a question about the way to code/store/markup/share different types of title too? I’m thinking in particular of those that originate on different parts of the item rather than uniform titles etc. or parts of the 245 (subtitles, parallel titles, part titles, etc, etc[*]). I’m not sure I’m keen on the idea- I’m hiding behind the defence of just flagging this up- but a title as a resource does let us say more about what sort of title something is:

Parallel title
Cover title
Added title page title
Caption title
Running title
Spine title
[**]

These could I suppose be separate properties (bf:parallelTitle, bf:coverTitle, etc) but I imagine there would then be overheads in the complexity of searching and indexing if you wanted to search by all sorts of title. Alternatively,

<instance> bf:title _:bnode666 .
_:bnode666 a bf:CoverTitle .
_:bnode666 rdfs:label “The travels of Ibn Battuta” .

(BTW I’m not making any particular statement in favour of blank nodes rather than _:bnode666 being replaced with a named resource). I think this would still pass Owen’s sparql query no matter what the kind of title was. I notice that the current Bibframe website suggests somewhere in between:[***]

<instance> [ a bf:Title ;
                    bf:subtitle "history of the WLSC" ;
                    bf:titleType "spine" ;
                    bf:titleValue "--Ahead of their time :" ],

using strings for the kind of title and with separate properties for instanceTitle, keyTitle, and titleStatement.

[*] I confess this kind of cataloguing bread and butter I’ve been interested to see addressed more explicitly in Bibframe and been intrigued that it hasn’t been in favour of many debates on eg annotations.
[**] See eg  http://www.loc.gov/marc/bibliographic/bd246.html
[***]see the example here: http://bibframe.org/vocab/titleVariation.html:

Thanks,

Tom

---

Thomas Meehan
Head of Current Cataloguing
Senate House Hub
Library Services
University College London
Gower Street
London WC1E 6BT

[log in to unmask]

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: 15 May 2015 01:13
To: [log in to unmask]
Subject: Re: [BIBFRAME] RDF dual properties... can be a cataloging question

On 5/14/15 2:36 PM, Robert Sanderson wrote:



On Thu, May 14, 2015 at 1:25 PM, Karen Coyle <[log in to unmask]<mailto:[log in to unmask]>> wrote:
On 5/14/15 9:21 AM, Owen Stephens wrote:
I don’t see a problem with allowing string properties when there is no question of there being a resource - but that’s a decision BIBFRAME should make, not the implementors. The problem I have is with letting the implementor/data dictate whether you have a string or a resource (or a date etc.) in any particular instance.

Turning titles (MARC 245) and other areas of bibliographic description into resources is not a slam-dunk, IMO. If we go with Rob's "all objects are resources"  are we saying that a title is semantically as much of a resource as a creator? Will our data reflect the difference between a string as resource and a rwo as resource? Does that matter?

If there are two properties of the same "thing" (like title and subtitle) then clearly there is a thing that has those properties, not just a single string.  Perhaps I'm being naive but it doesn't seem very complex :)

Well, we were talking about strings vs. things -- if you code the title as having multiple properties then it has to be a node to keep that structure. Ray showed a simple example:

<http://bibframe.example.com/workX><http://bibframe.example.com/workX>   bf:title   “Lord of the Flies” .

but I assume that it could have been a more complex title

<http://bibframe.example.com/workX><http://bibframe.example.com/workX>   bf:title   “Moby Dick, or The Whale” .
<http://bibframe.example.com/workX><http://bibframe.example.com/workX>   bf:title   “ Concerto-symphony : for symphony orchestra in E-flat major ; Sonata no. 2 for piano in A major ” .

The MARC subfields are a particular coding of titles, but hardly universal. Obviously,  if you want to retain the parts that MARC defines, then you have multiple properties that need a node. But not everyone does, not even everyone using MARC:

LIBRIS (Nat'l Lib Sweden)
245

1 0

a Coyle's information highway handbook : a practical file on the new information order


LC
245

10

 |a Coyle's information highway handbook :  |b a practical file on the new information order /


Coding these, (in my awkward way) I come up with:

#1
<http://bibframe.example.com/workX><http://bibframe.example.com/workX>   bf:title   “Coyle's information highway handbook : a practical file on the new information order” .

or

#2
<http://bibframe.example.com/workX><http://bibframe.example.com/workX>   bf:titleResource  [
     bf:title  “Coyle's information highway handbook : a practical file on the new information order” ] .

or

#3
<http://bibframe.example.com/workX><http://bibframe.example.com/workX>   bf:titleResource  [
     bf:title  “Coyle's information highway handbook ;
     bf:subtitle "a practical file on the new information order” ] .

There are undoubtedly other ways to do this, but in these examples, bf:title is always a string. An earlier example used "rdfs:label" in a #2 example, but that is antithetical to the need to code title and subtitle, and could only be used with plain string titles, so it's just a different serialization of #1.

I assume there are also other ways to code this.

kc



Rob

--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305



--

Karen Coyle

[log in to unmask]<mailto:[log in to unmask]> http://kcoyle.net

m: +1-510-435-8234

skype: kcoylenet/+1-510-984-3600