bibo:lccn, false mapping from zotero:callNumber and call numbers in general

[sieh...@googlemail.com]

Hi,

The Zotero-Bibo mapping at https://www.zotero.org/trac/wiki/BiboMapping
states that a Zotero callNumber can be mapped to bibo:lccn - this is
wrong because a call number can come from of a lot of different system
- lccn is just only one single case.

This brought me to the question what a call number is and how to
encode it in Bibo. There already was s discussion in June 2008 which
came to no conclusion:
http://groups.google.com/group/bibliographic-ontology-specification-group/browse_thread/thread/6136ba48828b2760/c24a2a55e88921b1

The problem is that a call number can reference a a single copy of a
book (frbr:item), the book as a document, no matter which copy
(bibo:document), or even the concept a book is about (skos:Concept).
It all depends on the library or library collection you refer to,
because call numbers only make sense if you know which library you may
call in!

Nevertheless I think that Bibo could use a bib:callnum property like
this:

bibo:callnum a owl:DatatypeProperty ;
rdfs:label "call number"@en ;
rdfs:comment "Call number of a document or item in an undefined
call number system"@en ;
rdfs:isDefinedBy <http://purl.org/ontology/bibo/> ;
rdfs:subPropertyOf dct:identifier ;
rdfs:domain [ a owl:Class; owl:unionOf (bibo:Document
bibo:Collection frbr:Item) ] ;
rdfs:range rdfs:Literal .

The domain should definitely include frbr:Item but it could also
include bib:Document and bibo:Collection - otherwise we need empty
nodes to link a call number to a document. Compare:

<> a bibo:Document ;
bibo:doi "10.1142/S0217732306019475" ;
bibo:callnum "arXiv:astro-ph/0601007v2" .

<> a bibo:Document ;
bibo:doi "10.1142/S0217732306019475" ;
frbr:exemplar [
a frbr:Item ;
bibo:callnum "arXiv:astro-ph/0601007v2"
] .

Cheers,
Jakob

[Ross Singer]

Hrm, this is actually wrong on more levels than what you point out,
since LCCN isn't a call number at all: it's the Library of Congress
control number.

Callnumber /certainly/ should not be mapping to that property, since
it would pollute the potential for a very strong identifier, see:

http://lccn.loc.gov/36029351
http://lccn.heroku.com/36029351

with a very weak one:

PZ3.R799 Ch 1890z PS2736.R3

-Ross.

> --
>
> You received this message because you are subscribed to the Google Groups "Bibliographic Ontology Specification Group" group.
> To post to this group, send email to bibliographic-ontolog...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/bibliographic-ontology-specification-group?hl=.
>
>
>

[Bruce D'Arcus]

On Nov 11, 2009, at 7:49 AM, Ross Singer <rossf...@gmail.com> wrote:

> Hrm, this is actually wrong on more levels than what you point out,
> since LCCN isn't a call number at all: it's the Library of Congress
> control number.
>
> Callnumber /certainly/ should not be mapping to that property, since
> it would pollute the potential for a very strong identifier, see:
>
> http://lccn.loc.gov/36029351
> http://lccn.heroku.com/36029351
>
> with a very weak one:
> PZ3.R799 Ch 1890z PS2736.R3
>

Yes, what Ross said.

Bruce

[sieh...@googlemail.com]

> Callnumber /certainly/ should not be mapping to that property, since
> it would pollute the potential for a very strong identifier, see:
>
>http://lccn.loc.gov/36029351
>http://lccn.heroku.com/36029351
>
> with a very weak one:
> PZ3.R799 Ch 1890z PS2736.R3

So do you think the concept of a call number (also known as shelf
mark) should not be part of Bibo? I am working on an Ontology for
bibliographic items (http://purl.org/NET/DAIA and
http://www.gbv.de/wikis/cls/DAIA_Format/RDF) and would like to reuse
as much classes and properties as possible, but I have not found an
existing property for this purpose (beside mods:shelfLocator, but I am
not sure whether MODS can just be used like it was RDF:
http://www.loc.gov/standards/mods/).

Cheers,
Jakob

[Bruce D'Arcus]

On Sun, Nov 15, 2009 at 6:56 AM, jakob...@gbv.de
<sieh...@googlemail.com> wrote:
>
>> Callnumber /certainly/ should not be mapping to that property, since
>> it would pollute the potential for a very strong identifier, see:
>>
>>http://lccn.loc.gov/36029351
>>http://lccn.heroku.com/36029351
>>
>> with a very weak one:
>> PZ3.R799 Ch 1890z PS2736.R3
>
> So do you think the concept of a call number (also known as shelf
> mark) should not be part of Bibo?

Depends: what does a call number identify? Is the number for book x
the same in library a as it is in library b?

Bruce

[Ross Singer]

What's wrong with dcterms:LCC and dcterms:DDC? (Plenty, more on this
in a minute)

No, I'm not sure that a shelfmark has any place in bibo since it's not
directly useful to the objective of bibo, namely modeling citations.
Since shelfmarks can be locally specific, it won't be helpful to the
2nd researcher, taking the citation and trying to locate the referent.

Now, on to dcterms:LCC/DDC. The "problem" with these is that they
are: http://purl.org/dc/dcam/VocabularyEncodingScheme. So they
themselves are their own resources. This isn't necessarily bad: we
can then say /where/ the class number is from (by this I mean library,
not scheme), but it's a hell of a lot more complicated. To start,
what is the appropriate way to relate the bibo:Document to the
dcterms:LCC? dcterms:subject? dcterms:identifier?

I don't know.

I'm glad to see you've started working on the RDF vocabulary for DAIA
- this will be very useful.

-Ross.

On Sun, Nov 15, 2009 at 6:56 AM, jakob...@gbv.de
<sieh...@googlemail.com> wrote:
>

[Bruce D'Arcus]

On Sun, Nov 15, 2009 at 10:41 AM, Ross Singer <rossf...@gmail.com> wrote:
> What's wrong with dcterms:LCC and dcterms:DDC? (Plenty, more on this
> in a minute)
>
> No, I'm not sure that a shelfmark has any place in bibo since it's not
> directly useful to the objective of bibo, namely modeling citations.

So is it fair to say that the domain of such a thing really ought to
be a frbr;Item,which by definition is out of scope for BIBO (we're
focused somewhere at the expression or manifestation level)?

Aside: part of the problem is that Zotero is not really designed for
global data-sharing; neither in the UI, nor the data model, nor
import/export support. The data is effectively understood as generic
"user data", which can get pushed around. So in that context, it's not
surprising that call numbers and isbns and titles all get grouped
together without distinction.

But I wish we could work towards moving away from this model.

Bruce

[Ross Singer]

On Sun, Nov 15, 2009 at 11:01 AM, Bruce D'Arcus <bda...@gmail.com> wrote:

> So is it fair to say that the domain of such a thing really ought to
> be a frbr;Item,which by definition is out of scope for BIBO (we're
> focused somewhere at the expression or manifestation level)?
>

Well, as with all things, "it's not that simple". There /are/
"official" (I guess) LCCs and DDCs that can be associated with a
particular manifestation (which, I think, we can find some agreement
between bibo and MARC): the MARC 050 and 082, respectively, contain
some sort of "standardized" call number. Now, I have no idea how
useful these are outside of determining subjects.

Call number, obviously, has a lot of value for locating a particular
resource. Esp. if I'm saving something that I, personally, want to
find again later.

So I guess I see two possibilities here: 1) use dcterms:subject and
link to dewey.info or some lcc.info-like analog for LCC and let
something else (frbr, RDA, something) handle items and punt on this in
bibo or 2) add some predicates in bibo to deal with shelfmarks.

The problem with #2 is that it seems either too simplistic
(bibo:shelfmark) or too complicated (bibo:ddc, bibo:lcc, bibo:nlm,
bibo:udc, etc.).

My gut feeling is that this is outside of scope for bibo, but I'm not
married to that.

-Ross.

[sieh...@googlemail.com]

Bruce wrote:
> So is it fair to say that the domain of such a thing really ought to
> be a frbr:Item,which by definition is out of scope for BIBO (we're
> focused somewhere at the expression or manifestation level)?

Ross wrote:
> My gut feeling is that this is outside of scope for bibo, but I'm not
> married to that.

Agreed. Instead of trying to squeeze call numbers in bibo, we should
admit that bibo is not meant to hold every possible piece of data that
is managed in any other bibliographic management system.

-Jakob