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

[Karen Coyle]

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 <http://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.

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

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.

kc

-- 
Karen Coyle
kcoyle at kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-bibliography/attachments/20100525/759ee40d/attachment-0001.html>