RE: Disjointedness of FRBR classes

Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:


>> This is one of the things that worries librarians
>> about moving from MARC, which is a stand-alone record, to linked data.
>> They are afraid of parts getting lost or not been available when
>> needed. I presume that we will have a "transfer" format that
>> encompasses the entire "bibliographic record" for data exchange.
>
> I think that the notions of "open-world assumption", VoID Dataset,  
> and "concise bounded description" are relevant here. Maybe JSON is  
> worth mentioning also.

Unfortunately, the library cataloging community does not subscribe to  
the "open world assumption" and neither FRBR nor RDA are designed with  
that in mind. The cataloging rules are designed to result in a  
complete or sufficient bibliographic description that isn't defined in  
terms of a serialization but in terms of minimum content. RDA has core  
data elements that are required. FRBR, RDA, and cataloging in general  
are designed as closed worlds. This is a discussion we need to have as  
a wider community, but if it is embraced by the cataloging community  
it will be a significant change to their thinking. And we can't *make*  
them think it. They have to decide that it has value within their goals.


> It would be better to say there is a cardinality constraint of 1 on  
> the frbr:isAnExemplarOf property.

Jeff, you can restate it however it makes sense to you.

>
>> which
>> in turn must manifest a FRBR:Expression of a FRBR:Work. Everything is
>> always at least:
>> W|WE|WEM|WEMI. No bibliographic resource can be "just" an Item or a
>> Manifestation. At least, NOT the way that FRBR is defined. An Item is
>> always an Item *of*...
>
> As I read it, there is a many-to-many relationship between  
> frbr:Manifestation and frbr:Expression that undermines any tree-like  
> notion of WEMI hierarchy.

Right, it's not a tree, it's a multi-hierarchy. That doesn't really  
undermine anything, it just makes it even more complex.


> I didn't mean to imply that these two classes should be treated as  
> disjoint. I meant to imply that they should be treated as classes,  
> not literal values.

Again, I think that will be awkward for multi-format resources. It  
also tends to confound the publication format (monograph, serial),  
intellectual content (biography, poetry, visual art), expression type  
(text, audio/visual, still image) and physical characteristics (print  
on paper, moving image and sound on 35mm film, stone object).

> I'm not opposed to "primary format" (or more precisely "primary  
> class") as a basis for edit templates. What I'm opposed to is  
> "primary format/class only". On the surface it seems simpler to say  
> things can only be of one type, but in the library domain we gouge  
> rather than scratch this surface. I should be able to say that  
> something is both a Book and a Movie and have all the corresponding  
> properties of both at my disposal. Any other workaround is bound to  
> be weird.

You can do that today in MARC -- in fact, there was a whole change to  
MARC in the late 1990's called "format integration" that achieved this  
at a certain amount of expense. You can use any MARC field in any MARC  
record, regardless of the primary format (which is a hold-over from  
the original MARC design that we are stuck with until we develop a new  
format for the data). You can use multiple 006 and 007 fields to  
describe characteristics of any formats you wish within the same  
record. Which one is primary can be arbitrary if there are multiple  
but equal formats. So you do have all of the properties of both at  
your disposal. Admittedly, in MARC it's ugly and hard to manage, but  
that's the intention and it is applied in actual cataloging.

kc

>
>>
>> But the library determination of type is not based on intuition.
>> Libraries have rules that determine which template you choose. That's
>> because our use case is that we want to use each other's data and it
>> takes work to change someone else's Book to your Serial if you
>> disagree on the primary format. If we didn't need to share so deeply,
>> the rules would be less important.
>
> IMO, libraries wouldn't have to depend so heavily on rules if they  
> catered more to intuition. I don't think the real problem is format  
> differences so much as it is element vocabulary differences. If the  
> element vocabulary(ies) are well-defined (specifically using  
> RDFS/OWL) and intuitive, then more people/systems would be able to  
> contribute to and use the Web of Data via open-world assumption  
> microdata structures rather than closed-world assumption macrodata  
> structures.
>
> Jeff
>
>>
>> kc
>>
>> >
>> > Jeff
>> >
>> >>
>> >> kc
>> >>
>> >> > Books, Movies, and the promotion of modern "digital"
>> >> > manifestations/items to 1st class objects makes me appreciate
>> >> > http://purl.org/spar/fabio as an efficient RDF vocabulary for the
>> >> > library domain. Unfortunately, http://purl.org/spar/fabio/ doesn't
>> >> > roll off the tongue like http://schema.org/.
>> >> >
>> >> > OTOH, "FRBR" and Schema.org seem to be equally blame-worthy in the
>> >> > sense that both are namespace-centric and single-type-at-a-time
>> >> > oriented. I suspect this is just a passing phase for Schema.org,
>> >> > though.
>> >> >
>> >> > Jeff
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Jakob Voss [mailto:Jakob.Voss@gbv.de]
>> >> >> Sent: Monday, October 31, 2011 7:37 PM
>> >> >> To: ian.davis@talis.com
>> >> >> Cc: tim.hodson@talis.com; public-lld@w3.org
>> >> >> Subject: Re: Disjointedness of FRBR classes
>> >> >>
>> >> >> Hi Ian,
>> >> >>
>> >> >> > I'm not party to the full discussion but in our bib data
>> modelling
>> >> >> > at Talis we moved on from FRBR towards describing the real
>> >> >> > objects, not an abstract model of them.
>> >> >>
>> >> >> If you discuss about FRBR long enough, works, manifestations,
>> >> >> expressions
>> >> >> and items become pretty real ;-)
>> >> >>
>> >> >> > Rob Styles at Talis blogged about it a couple of years ago but
>> his
>> >> >> > blog is temporarily offline. Here's a substantial quote from it
>> >> >> though:
>> >> >> > http://www.frbr.org/2009/11/13/styles-bringing-frbr-down-to-
>> earth
>> >> >>
>> >> >> Does this reflect current work at Talis on modeling/describing
>> >> >> bibliographic
>> >> >> resources?
>> >> >>
>> >> >> http://consulting.talis.com/2011/07/british-library-data-model-
>> >> >> overview/
>> >> >>
>> >> >> I don't expect Talis and British Library to implement full FRBR,
>> but
>> >> I
>> >> >> wonder about the lack of any concept of holdings, items, copies
>> etc.
>> >> >> compared to at least editions. Do the central URIs in the BL
>> model
>> >> >> represent physical books? What about books with two or more
>> >> >> copies in the BL - two unrelated URIs? Are there no relations
>> >> >> between multiple editions of the same book?
>> >> >>
>> >> >> Jakob
>> >> >>
>> >> >> --
>> >> >> Verbundzentrale des GBV (VZG)
>> >> >> Digitale Bibliothek - Jakob Voß
>> >> >> Platz der Goettinger Sieben 1
>> >> >> 37073 Goettingen - Germany
>> >> >> +49 (0)551 39-10242
>> >> >> http://www.gbv.de
>> >> >> jakob.voss@gbv.de
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Verbundzentrale des GBV (VZG)
>> >> >> Digitale Bibliothek - Jakob Voß
>> >> >> Platz der Goettinger Sieben 1
>> >> >> 37073 Goettingen - Germany
>> >> >> +49 (0)551 39-10242
>> >> >> http://www.gbv.de
>> >> >> jakob.voss@gbv.de
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Karen Coyle
>> >> kcoyle@kcoyle.net http://kcoyle.net
>> >> ph: 1-510-540-7596
>> >> m: 1-510-435-8234
>> >> skype: kcoylenet
>> >>
>> >>
>> >
>> >
>> >
>> >
>>
>>
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net http://kcoyle.net
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet
>>
>>
>
>
>
>



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

Received on Wednesday, 2 November 2011 12:05:18 UTC