[open-bibliography] More verbs. Electronic 'Items' (Yes, another FRBR thread)

Tue Jul 13 15:43:56 UTC 2010

> -----Original Message-----
> From: open-bibliography-bounces at lists.okfn.org 
> [mailto:open-bibliography-bounces at lists.okfn.org] On Behalf 
> Of Weinheimer Jim
> Sent: 13 iulie 2010 13:24

> 
> So, this led me to consider if there really is such a thing 
> as a "manifestation" and if not, what is it? I have decided 

Another abstraction ? :-)

> 
> My question is: if the manifestation is only a matter of 
> definitions (IF title, publication information, dates etc. 
> are all the same, then it is a duplicate; or if the date is 
> within x number of years, it is a copy, and so on and so on) 
> it seems as if this would be a perfect candidate for 
> automatic sorting and display. If people (or computers) 
> create the metadata record, they would always copy *exactly 
> what they see* and instead of puzzling out which 
> "manifestation" this item belongs to manually, let the 
> machine sort out the displays.

Hm, hm ... I'm sure you spot easily in 93.2% of the cases which are the features of an item which
are not specific to that item (within the series we use to call edition) :-)

> 
> What would this mean in reality: most information currently 
> in the manifestation would go to the item, and then when 
> processing the item (using xml, rdf, RDBMS or whatever) any 
> information that is the same as in another item would be 
> replaced with a URI to that information. As far as displays 
> of the "group of items" goes, that could be left to the 
> discretion of each database manager.

I still believe that the "common factor" (of the items) conventionally called "manifestation" is
useful, from a practical point of view.

For instance, suppose we produce the metadata using the RDF formalism. Let's say we have 4 nice
literals:

L1: THE IMITATION OF CHRIST

L2: BY Thomas A Kempis

L3: THE BRUCE PUBLISHING COMPANY

L4: November 5, 1940

and suppose you have in the catalogue 3 items a, b, c you decide to associate with these 4 literals.

a isbd:titleProper L1
a isbd:statementOfResponsibility L2
a isbd:publisher L3
a isbd:date L4

...

c isbd:date L4

... in totto 12 rdf:statements.

Now, suppose you notice the common factor of the 3 items and you "invent" an abstraction m, let's
call it "manifestation" (only for the sake of the discussion :-) and you produce the rdf:statemens:

m isbd:titleProper L1
m isbd:statementOfResponsibility L2
m isbd:publisher L3
m isbd:date L4

a frbr:exemplifies m
b frbr:exemplifies m
c frbr:exemplifies m

... in totto 7 rdf:statements.

In the first case you have n (items) x k (literals) statements and in the second case you have n + k
statements.

In a catalogue where n use to be 1 or 2, your solution is OK. But in a shared catalogue where n >> 2
?

> 
> I think instituting something like this would make it far 
> easier both for creating records and training, while 
> everything would be much more accurate than what we have now.

Maybe for the edge cases. But for the usual ones, I don't think is that hard. Even my numismats
learn how to distinguish between the properties of an issue vs. the properties of an exemplar (coin)
:-)

Dan Matei