[open-bibliography] OKFN blog: Bibliographica, an Introduction

Tue May 25 15:40:49 UTC 2010

First off, I want to apologize if there are, like, three pages of Talis
.sigfile stuff at the bottom of everything I post.  I don't know if that's
just something I get or if everyone gets the joy of that...  I'll try to see
if it can be turned off.

On Tue, May 25, 2010 at 10:58 AM, Karen Coyle <kcoyle at kcoyle.net> wrote:

>  On 5/23/10 7:38 PM, Ross Singer wrote:
>
>   If IFLA is going to use the most obtuse language and identifiers
> imaginable to define FRBR, the actual practitioners of the web will use the
> vocab.org/frbr/core vocabulary, not IFLA's.
>
>
> And they'll already be out of date, unless someone updates vocab.org,
> which would be a good idea. The IFLA registered properties include the
> attributes and relationship properties, while vocab.org is just the 'core'
> as it says here. In some cases care will be enough, but it's not all of
> FRBR.
>
> No, it but it also doesn't have to be.  I guess unless "FRBR" becomes
trademarked by IFLA, there are can be various interpretations (and
subsequent vocabularies).  People will use what ever makes the most sense to
them and it may not be IFLA/RDA's "blessed" interpretations.

>
>  Also, going back to RDA's arcane property names -- one of the reasons
> they are so awful is because they are trying to do too much.  They are
> implicitly making more than one statement at a time.  There is no need for
> configurationOfPlaybackChannelsManifestation and
> configurationOfPlaybackChannelsExpression (etc.) because you should only be
> asserting this to the resource at hand (i.e. the Manifestation or the
> Expression).  All you need is "configurationOfPlaybackChannels" (whatever
> the hell that means).  By having an
> "otherDistinguishingCharacteristicOfTheExpression" predicate on something
> that is really, say, a manifestation, you are saying two things, only one
> that is really about the thing that you are talking about (which is, this
> thing has an Expression, but not actually what it is.  The other assertion
> -- otherDistinguishingCharacteristic -- should actually be asserted on the
> Expression).
>
>
> You wouldn't believe what a religious war that is! But before getting into
> that, one needs to contemplate the difference between RDF and other data
> declarations. In RDF, you cannot redefine a property by placing it in a
> hierarchy, as you can with, say, XML. In RDF, the properties belong to a
> class (say a FRBR entity) and they belong to that class no matter where they
> are placed in relation to other properties. So (to use an easier example)
> Title of the Work is defined as being of class Work. Title proper is defined
> as being of class Manifestation. You cannot redefine their class in a usage.
> In fact, it works in the opposite way -- if you declare Title proper to be a
> property of some resource, that resource "inherits" the class Expression by
> definition. Jon Phipps explains this well, and I had hoped that he had done
> a blog post on it but I can't find one. If you run into him, ask him for his
> explanation. Essentially he will tell you that you have described how things
> work in XML, but that is not true in RDF.
>

Actually, if this is what Jon said, I hate to say it, but Jon's wrong (or
this is being taken out of context).  Yes, if a particular attribute has a
particular FRBR entity as its domain or range, then indeed, using that
property will infer that the object or subject is the entity that it's
associated with.  However, if the domain or range is left open (like current
properties are, as I understand it), then this issue is moot - you use
dcterms:title or rda:titleProper or something on a manifestation and say
it's part of an expression (which has its own dcterms:title/rda:titleProper
assertions), etc.  The relationships between FRBR entities then becomes
optional.  If there is not enough data to describe the WEMI chain, don't.

> That said, for the RDA folks it is imperative (religiously so) that each
> RDA property be associated with one and only one FRBR entity. I can't
> explain why, but they feel very strongly about it. Essentially, if you use a
> property with a different FRBR entity than the one they have defined, then
> you aren't doing RDA. So you may notice that for every one of those
> gawd-awful RDA properties in the Registry there is also a property that is
> "classless" -- and that property can be used in a situation that does not
> conform to RDA's assertion of FRBR.
>
>
>>
>  I don't disagree with your point.  However, if all we have is what is
> really more or less a manifestation with subjects, creators, etc. and not
> really enough definitive information to effectively define a work or an
> expression, I think you just have to model what you've got.
>
> HMMM. I don't know how else to say this, but if you have subjects and
> creators you have a mix of Work and Manifestation, and by inference
> Expression. This is why forcing things into a FRBR *structure* is such a bad
> idea -- most people aren't going to be thinking that adding subjects means
> that they've added Work-level properties. And this is why I'm trying to
> figure out a way that we can create data any which way and still consider
> subjects to be part of the Work in those situations where it matters. I
> think we can do this by assigning the properties to their appropriate
> classes, and let the "classness" carry the FRBR entities, not some record
> structure.
>
> I guess my question at this point becomes, do we wring our hands and worry
over the minutiae of making sure our horribly imperfect data maps perfectly
to a theoretical, platonic ideal of what library data should be or can we
just assume some fuzziness with the legacy data and start building things
the best we can (without the architectural astronautics) with the stuff
we've got now?  Is anybody really going to care, in the end, if the subjects
have been asserted against what is really a manifestation?

-Ross.

> kc
>
> --
> Karen Coyle
> kcoyle at kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
>
> ------------------------------
> Please consider the environment before printing this email.
>
> Find out more about Talis at http://www.talis.com/
> shared innovation™
>
> Any views or personal opinions expressed within this email may not be those
> of Talis Information Ltd or its employees. The content of this email message
> and any files that may be attached are confidential, and for the usage of
> the intended recipient only. If you are not the intended recipient, then
> please return this message to the sender and delete it. Any use of this
> e-mail by an unauthorised recipient is prohibited.
>
> Talis Information Ltd is a member of the Talis Group of companies and is
> registered in England No 3638278 with its registered office at Knights
> Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
>
> _______________________________________________
> open-bibliography mailing list
> open-bibliography at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/open-bibliography
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-bibliography/attachments/20100525/e0670e1a/attachment-0001.html>