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

Mon May 24 02:38:12 UTC 2010

On Sun, May 23, 2010 at 8:26 PM, Karen Coyle <kcoyle at kcoyle.net> wrote:

> Quoting William Waites <william.waites at okfn.org>:
>
>
>
>> Interesting. I wonder why they wouldn't just adopt the existing
>> namespace.
>>
>
> Well, they *are* the developers of FRBR, so in a sense the FRBR
> namespace should be decided by IFLA, since they will be the ones
> maintaining the definitions. If you look at what is in the metadata
> registry, you will see that FRBR has evolved since the vocab project
> defined it, and it would be best to use the one that is the most up to
> date.
>
>
>  Their URIs are also funny.
>>
>>    :WarAndPace a <http://iflastandards.info/ns/fr/frbr/frbrer/1003>
>>
>> regardless of namespace, it's not nice to give your classes numbers
>> instead of names.
>>
>
> That's one of those religious questions :-). Some folks think that
> using names is not nice because it isn't language neutral. You'll find
> arguments no matter which method you use. For RDA properties, the RDA
> folks did decide that they wanted language-based URIs, and they've
> ended up with things like:
>
> http://rdvocab.info/Elements/configurationOfPlaybackChannelsManifestation
>
> http://rdvocab.info/Elements/otherDistinguishingCharacteristicOfTheExpression
>
> Those make numbers look good.
>
> Right, but just because those are wrong, doesn't make IFLA's decision
right.  I realize, understand (and part of me even sympathizes with) the
librarian argument for attributes with no baked in semantic meaning, but
that fact of that matter is that the semantic web (hell, the web, period,
from HTML, XML, RDF, programming languages, etc.) is built on readable
labels and, to date, the language of those labels has been English (although
there is some disagreement as to *which* English).  That battle is lost.  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.

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).

>
>
> So in response to Ross's comment:
>
>
>  After all, if the only data you have is
>>
> manifestation level, it's not possible to (or necessary) to define the work
> or expression.  That's the benefit of the open world model, somebody else
> can fill in those parts you don't currently know.
>
> ... in fact, a Manifestation level record would have no creator and no
> subjects, also no language of text. FRBR, IMO, is a huge mess the way
> that it is actually written, and I am determined to find a way to make
> it more useful for real life applications. But the fact is that a
> "normal" bib record with author, title, publisher, subjects, is a
> mixture of WEM. There really is no such thing as a Manifestation
> record without WE. So that's why I feel like putting Manifestation as
> a type on the records is incorrect and could in the long wrong create
> more confusion (than FRBR already does on its own).
>

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.

-Ross.

>  On the other hand if someone wants
>
>  to say that X's translation into Estonian of "100 Years of Solitude" is
>> particularly bad, this type of statement goes at the Expression level.
>> But will they know that without help? I'm not sure how to handle this
>> sort of thing from a user interface perspective.
>>
>
> You are right that this should be at the Expression level, but I
> despair of ever having WEMI understood by the general Internet
> population when even catalogers are struggling with it. You are also
> right that if there is going to be any understanding of it, the UI is
> key. I'm fairly comfortable with the choice made by Open Library to
> develop Work entities, and to combine Expressions and Manifestations
> as a single entity. For texts, the Expression has few properties, the
> primary one being language/translation. It is possible that if we use
> the role properties (such that author, translator, conductor, director
> would be roles that link an Agent to a resource), we can determine
> that certain roles are Work level and others are Expression level, and
> we can possibly infer expressions. But how to get that note pointing
> to the Expression and not the Manifestation or Work... I'm not at all
> sure about that.
>
> kc
>
>
>
>> Cheers,
>> -w
>>
>>
>> --
>> William Waites           <william.waites at okfn.org>
>> Mob: +44 789 798 9965    Open Knowledge Foundation
>> Fax: +44 131 464 4948                Edinburgh, UK
>>
>> _______________________________________________
>> open-bibliography mailing list
>> open-bibliography at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/open-bibliography
>>
>>
>
>
> --
> Karen Coyle
> kcoyle at kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>
>
> _______________________________________________
> open-bibliography mailing list
> open-bibliography at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/open-bibliography
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-bibliography/attachments/20100523/5ade2ee0/attachment-0002.html>