[libdb-develop] Fwd: Re: libdb and FRBR

[Morbus I. <mo...@di...>]

 >Date: Fri, 30 Jan 2004 17:31:05 -0500
 >To: Daniel Chudnov <dc...@um...>
 >From: Morbus Iff <mo...@di...>
 >Subject: Re: libdb and FRBR
 >
 >
 >I'll be CCing this to the libdb-develop list at Sourceforge
 >sans any identification. If you want jump on board and
 >introduce yourself, responding to my comments, have a blast.
 >
 >>My understanding of FRBR, as a spec and meme, is that they are just what
 >>they claim -- functional requirements, but for users, not systems.
 >
 >Exactly. It's a concept model, not a data model.
 >
 >>Seeing that you've modelled its core concepts as literal tables, I'm
 >>wondering what your processing model will be, and how you're planning to
 >>do basic object storage.
 >
 >Heh, heh. Why don't you talk to uh, my um, marketing department <g>.
 >
 >>Hmm, let me try that again:  How do you plan to populate the FRBR
 >>primitives tables (work, expression, etc.)?  Are you sucking in
 >>MARC/MODS/etc records and running a local implementation of OCLC's FRBR
 >>algorithm on them?  If so, are you discarding the original source
 >>metadata?  Will you count on users to identify the relationships, or will
 >>it be semi-/fully-automated?
 >
 >Aaaahh. Much better! <g>
 >
 >Yes, there will be aggregated data. This shouldn't be too surprising,
 >since my latest book has been O'Reilly's SPIDERING HACKS. The first
 >type of data I'm *specifically* attacking for LibDB is movies, but
 >if you looked at the database tables without that knowledge, it
 >may not be immediately obvious (ie. the database tables are not
 >dependent on an implied media). As such, data would be sucked
 >down from IMDb, but for books and other standard librarian
 >stuff, it'd be sucked in through (whatever formats LibDB
 >supports, which could be MARC, MODS, etc.).
 >
 >The original source metadata would be discarded. LibDB will
 >support export formats (in a RESTian URL structure), such that
 >you'd be able to get data as RDF, MARC, FOAF, etc., etc.
 >
 >With that in mind, the planned workflow for movies:
 >
 > 1) User types in movie name and year.
 > 2) User gets back either:
 >
 >    a) the matching movie from IMDb, split up in a
 >       giant form that doesn't mention any FRBR terms.
 >
 >    b) a list of matching movies, to which they'd choose
 >       the right one, and be faced with a), above.
 >
 > 3) user verifies all information.
 >
 >There's a heckuva lot missing between 2a and 3, and that's mainly all
 >interface/forms. I don't have any plans to mention the term "relationships",
 >whatsoever. LibDB will handle all the core relationships implicitly:
 >it will create the work/expression relationship based on the data
 >sucked down, and the expression/manifestation/item relationships
 >based on user data ("i own the dvd, it's in the third box, and
 >I thought the movie sucked").
 >
 >Relationships with Group 1 and Group 2 entities (for movies, cast,
 >crew, and companies) is handled automatically within the code.
 >The user will merely see a list of all the people who starred in
 >the movie, all the people/companies who worked on the movie,
 >and they'll have the option of choosing which info they want
 >to save into the database (though, I'm up in the air on that
 >one), as well as the ability to override any of the "roles"
 >relationships.
 >
 >Now again, I won't mention "roles" at all.
 >The interface would look something like:
 >
 > "Julia Roberts"         Cast Member  "CharacterName"
 > "Something Someone"     Crew Member  [ "2nd Post Production Assistant" ]
 > "Artisan Entertainment"              [ "Distributor" ]
 >
 >In this example, the [] indicates a select/popup box, and "2nd Post
 >Production Assistant" is the data received from IMDb. The user would
 >be able to (as I would) pick the more generic "Post Production
 >Assistant" from that select box. The select box is populated
 >with all the roles the database knows of (in a future version of
 >the database, roles will be associated with an authority/form,
 >so that if you were adding a "book", you wouldn't see "Post
 >Production Assistant", and if you were adding a "film", you'd
 >see "Titles" instead of "Typesetter").
 >
 >Likewise, Group 3 entities would be defined as relationships, but
 >to the end user, they'd just see a big text box that says "Enter
 >Concepts, one per line", "Enter Events, one per line". I'm still
 >debating on having a popup of known Concepts, Events, and just
 >having the user pick from a dozen possible popups (along with
 >write-ins).
 >
 >Once the user has gone through all the data, making changes where
 >they'd see fit, data verification would occur. This is largely
 >grey area at the moment, but stuff like this would happen:
 >
 >  "The concept 'Murder' exists, and has been assigned."
 >  "The event 'Sherwood Forest' did not exist, and has been assigned."
 >
 >  "You already have a person in the database named 'Julia Roberts'.
 >   Is this the same 'Julia Roberts' that was involved with:
 >
 >        * Work 1 (ie. movie 'Erin Brockavich')
 >        * Work 2 (ie. movie 'Runaway Bride')"
 >
 >and so on.
 >
 >Of course, at some point, users will want to more granularly define
 >relationships. They may want to "create a relationship type" called
 >"Sister", and then "make a relationship" between "person Mary Kate" and
 >"person Ashley". Those sorts of relationships can't be implied easily
 >from any data that currently exists. However, once they're created, the
 >relationship becomes usable to other application (ie. when a user exports
 >either of those sisters as RDF or FOAF data).
 >
 >Does this answer your questions?

-- 
Morbus Iff ( cheese and rice saves )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus