[Data-modeling] Library of Congress and Dewey Classifications

[Ed Laurent]

In my last comment I should have said the codes should be considered as
topics.  If they are topics then they can be linked to their classification
system and fit the mold of the existing code topics (e.g., motorcycle part
numbers) of the types that I referred to. They can't be machine readable
strings then can they! However, if they are not topics, then they should
probably be machine readable strings.

-Ed


On Tue, Mar 18, 2008 at 2:28 PM, Ed Laurent <spatial.db at gmail.com> wrote:

> My initial thought is to list the full codes as machine readable strings
> with library disambiguation. These numbers are essentially unique codes in
> unique but purposefully similar classification systems. Because the topics (
> i.e., books) that the codes refer to are themselves unique and have
> multiple codes, some form of cross reference is needed to link multiple
> codes from multiple classification systems to the same topics. My Classification
> code<http://www.freebase.com/view/schema/user/spatialed/default_domain/classification_code>type and Motorcycle part number types (both
> manufacturer<http://www.freebase.com/view/schema/user/spatialed/motorcycle/motorcycle_part_number_manufacturer>and
> retailer<http://www.freebase.com/view/schema/user/spatialed/motorcycle/motorcycle_part_number_retailer>)
> provide examples of how I'm handling these kinds of situations. I don't
> think the Dewey Decimal system is very different. It is unfortunate to hear
> that the Library of Congress codes are not unique for each publication and
> edition. I thought that was the point of the L of C system!
>
> -Ed
>
>
> On Tue, Mar 18, 2008 at 1:55 PM, Kirrily Robert <kirrily at metaweb.com>
> wrote:
>
> >
> > ----- "Jeff Prucher" <jeff at metaweb.com> wrote:
> > >
> > > Here are some example Dewey numbers for the 1994 Modern Library
> > > edition of
> > > Adam Smith's "An inquiry into the nature and causes of the wealth of
> > > nations" from different libraries:
> > > 330.153
> > > 330.15
> > > 330.1
> > > 330
> > > 330 S642i 1994
> > > 330.153 SMI 1994
> > > 330.15 SMITH 1994
> > > 330.153 S642w, 1994
> > > 330.15 Sm51i
> > > 330.153 Sm51 1994
> > >
> > > The obvious thing to do would be to cut the value after the space,
> > > since the
> > > additional data seems largely to do with disambiguating the edition
> > > from
> > > others in that library. That would still leave us with four different
> > > values, which in this case are at least hierarchical, but I've seen
> > > others
> > > (can't find them right now, unfortunately) where different libraries
> > > had
> > > values like "330" and "808".
> >
> > With regards to the hierarchical values in the 330 namespace, at least
> > they're all compatible!  I mean, looking at that set, it seems to me that
> > 333.153 is the "correct" classification and any library that uses less
> > precision simply does so because their collection is small (at least in that
> > area) and they don't need the precision.
> >
> > So for cases like this, I'd tend to say "the most precise value
> > possible, without causing incompatibility."
> >
> > A counter example:
> >
> > 330
> > 330.153
> > 330.152
> >
> > The most precise value possible without incompatibility would be 330.15
> >
> > This works for anything that doesn't diverge until after the decimal
> > point.  In your 330/808 example, I dunno.  Makes me think we should store
> > catalogue numbers as a CVT:
> >
> > * catalogue number
> > * numbering system (dewey/loc/other)
> > * library we got this one from
> >
> > > 3) Is it worth even trying to capture these values?  What advantages
> > > are
> > > there that would make it worth trying to wrangle this rather messy
> > > dataset?
> >
> > Too early in the morning for philosophy.  All I can say is it gives me
> > warm fuzzy feelings, in a general sort of way, and I'd like us to have this
> > data.
> >
> > K.
> >
> > --
> > Kirrily Robert
> > Freebase Community Director
> > kirrily at metaweb.com
> >
> > _______________________________________________
> > Data-modeling mailing list
> > Data-modeling at freebase.com
> > http://lists.freebase.com/mailman/listinfo/data-modeling
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20080318/b2cef059/attachment.htm