libdb-develop Mailing List for LibDB (Page 5)
Status: Inactive
Brought to you by:
morbus
Menu
▾
▴
libdb-develop — Developer discussions and bickerings.
You can subscribe to this list here.
| 2004 |
Jan
(48) |
Feb
(58) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(29) |
Aug
(36) |
Sep
(5) |
Oct
(1) |
Nov
(32) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
(4) |
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <mo...@di...> - 2004-07-23 17:40:42
|
Project: LibDB Version: cvs Component: Documentation Category: tasks Priority: normal Assigned to: Anonymous Reported by: Morbus Iff Updated by: Little Nemo Status: active From The California Employment Development Department: Lighting Technicians are members of the production crew who set up and operate electrical lighting equipment for motion picture production. Lighting Technicians determine from the Chief Lighting Technician what the Photographer is attempting to accomplish and how the set will be lit. They also handle the hook-up of all electrical apparatus used, setting up and adjusting various types of lighting equipment. Little Nemo Previous comments: ------------------------------------------------------------------------ July 22, 2004 - 05:23 : Morbus Iff The provided libdb.mysql database schema contains a number of predefined role types, mostly from the film industry. Whilst most of them contain descriptions of what they actually entail, some are still missing. Those that are missing should be completed. ------------------------------------------------------------------------ July 23, 2004 - 05:34 : Little Nemo From filmsound.org: What is Audio Post-Production? ---------------------------------------------------------------------- Audio Post-Production is the process of creating the soundtrack for a visual program of some kind. Ever since silent movies began to talk, filmmakers have been looking to control and improve the quality of the sound of their creation. As soon as creators realized there was a way to control and enhance the sound of their pictures, Audio Post was born, and has been a fact of life ever since. In Television, audio was originally "live", like the visual program it was part of. As TV evolved, and the art form grew to include "videotaped" and "filmed" programming, the need for Audio Post increased. Nowadays, it would be difficult to find any feature film or television show that hasn't been through audio post. What is involved in Audio Post ? ---------------------------------------------------------------------- Audio Post usually consists of several processes. Each different project may need some, or all of these processes in order to be complete. The processes are: Production Dialogue Editing ADR (Automated Dialogue Replacement - if needed) Sound Effects Editing and Design Foley Recording (human sound effects recorded in sync with picture) Music Composition and Music Editing Mixing (also called re-recording) ------------------------------------------------------------------------ July 23, 2004 - 05:37 : Little Nemo From filmmusicmag: 3. What is an engineer (aka "scoring mixer") - A scoring mixer, also known as an engineer, works during the recording sessions to record and mix the music. The engineer is the primary technical resource at recording sessions, and oversees all technical aspects of the recording sessions. Scoring mixers work closely with composers and songwriters to make sure the recording process happens successfully, whether in a commercial studio or at a home project studio. Scoring mixers can also be a great source of technical information for composers and songwriters, providing up-to-date information about how current technology is used. ------------------------------------------------------------------------ July 23, 2004 - 05:40 : Little Nemo From the Directors Guild of Canada (of all places): Post Production Accountant(PPA) The Post Production Accountant is responsible for the coordination, supervision, and operation of the accounting department after principal photography has been completed. ------------------------------------------------------------------------ July 23, 2004 - 22:33 : Little Nemo Regarding Orchestra Contractors: From John Hopkin's Magazine: It is the contractor's job to hire the musicians, handle the payroll, and see to it that everyone abides by the union work rules. -- View: http://drupal.org/node/view/9441 Edit: http://drupal.org/project/comments/add/9441 |
|
From: <mo...@di...> - 2004-07-23 17:33:26
|
Project: LibDB Version: cvs Component: Documentation Category: tasks Priority: normal Assigned to: Anonymous Reported by: Morbus Iff Updated by: Little Nemo Status: active Regarding Orchestra Contractors: From John Hopkin's Magazine: It is the contractor's job to hire the musicians, handle the payroll, and see to it that everyone abides by the union work rules. Little Nemo Previous comments: ------------------------------------------------------------------------ July 22, 2004 - 05:23 : Morbus Iff The provided libdb.mysql database schema contains a number of predefined role types, mostly from the film industry. Whilst most of them contain descriptions of what they actually entail, some are still missing. Those that are missing should be completed. ------------------------------------------------------------------------ July 23, 2004 - 05:34 : Little Nemo From filmsound.org: What is Audio Post-Production? ---------------------------------------------------------------------- Audio Post-Production is the process of creating the soundtrack for a visual program of some kind. Ever since silent movies began to talk, filmmakers have been looking to control and improve the quality of the sound of their creation. As soon as creators realized there was a way to control and enhance the sound of their pictures, Audio Post was born, and has been a fact of life ever since. In Television, audio was originally "live", like the visual program it was part of. As TV evolved, and the art form grew to include "videotaped" and "filmed" programming, the need for Audio Post increased. Nowadays, it would be difficult to find any feature film or television show that hasn't been through audio post. What is involved in Audio Post ? ---------------------------------------------------------------------- Audio Post usually consists of several processes. Each different project may need some, or all of these processes in order to be complete. The processes are: Production Dialogue Editing ADR (Automated Dialogue Replacement - if needed) Sound Effects Editing and Design Foley Recording (human sound effects recorded in sync with picture) Music Composition and Music Editing Mixing (also called re-recording) ------------------------------------------------------------------------ July 23, 2004 - 05:37 : Little Nemo From filmmusicmag: 3. What is an engineer (aka "scoring mixer") - A scoring mixer, also known as an engineer, works during the recording sessions to record and mix the music. The engineer is the primary technical resource at recording sessions, and oversees all technical aspects of the recording sessions. Scoring mixers work closely with composers and songwriters to make sure the recording process happens successfully, whether in a commercial studio or at a home project studio. Scoring mixers can also be a great source of technical information for composers and songwriters, providing up-to-date information about how current technology is used. ------------------------------------------------------------------------ July 23, 2004 - 05:40 : Little Nemo From the Directors Guild of Canada (of all places): Post Production Accountant(PPA) The Post Production Accountant is responsible for the coordination, supervision, and operation of the accounting department after principal photography has been completed. -- View: http://drupal.org/node/view/9441 Edit: http://drupal.org/project/comments/add/9441 |
|
From: Morbus I. <mo...@di...> - 2004-07-23 15:57:22
|
See my responses in the previous email, but the following is a helpful bit of text from PAT...@bn... on the FRBR list: >The WG on FRBR/CRM Harmonization, while striving to "translate" FRBR into >OO formalism, has been thinking about the "form" attribute, assigned to the >Work entity in the FRBR Final Report. The reasoning was as follows: a Work >is "an abstract entity, there is no single material object one can point >to as the work" (FRBR Final Report p. 16); a work can therefore definitely >*not* have a "form". In order to "grasp" the work, you must have access to >at least an Expression, which in turn can be grasped IFF (no pun >intended...) a Manifestation thereof is available. The Manifestation can be >perceived by the senses, and the information received by our senses allows >us to analyze and typify or categorize the Expression embodied in the >Manifestation; among the typification possibilities, there is a >typification by "form": "I recognize this as being text" (at a very general >level), "I recognize this as being a theatre script, a prose poem, a haiku, >a short novel (etc.)" (at a more specific level). Among all the possible >expressions for a given work, you have to choose one as being best >"representative" for the work, and the "form" of that "representative >expression" is then supposed to be the "constraining super-type of the >work", that is: "if an expression does not fit in this category, then it is >an expression of another work". For instance: in the FRBR conventions, an >adaptation of a novel into a children's book is supposed to another work >(p. 17; I've always found that questionable, but that's another issue). >This means that the novel has a "representative expression" which has as >constraining super-type: "text - novel"; then you compare the expression >embodied in the children's book (which has as form: "text - novel for >children") to that representative expression and you find out that they are >different. Of course, an authoritative list for "constraining super-types" >of works is dramatically important in that process, because this is what >will determine your cataloging conventions and demarcating lines between >works. If I do not declare "text - novel for children" as a distinct >"constraining super-type", but only "text - novel", then a novel adapted >for children will remain just an expression of the novel as a work, not a >new work. This flexibility was intended in the FRBR model, as no one in the >world can positively say "This is not the same work" (it's basically just a >matter of taste...). -- Morbus Iff ( you, me, eropuri? aawwwwwWWWw yYeahahhHHAhhh ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
|
From: Morbus I. <mo...@di...> - 2004-07-23 15:56:02
|
From: Maja =CEumer <Maj...@nu...> on the FRBR list:
>But back to the serious i.e. FRBR matters. Regarding 'form of
>work': as you may have seen in the FRBR/CRM Heraklion meeting
>report, we already discussed the issue and decided that it is not
>a work attribute, but a constraining super-type of the work or,
>rather, type of Representative expression. (Martin, did I get
This I didn't know - thanks for the update. It would seem, then,
that one possible solution to my problem ("how should I restrict
the display of roles based on the type of work being added") would
be to create a hierarchical taxonomy of types, such that a "super
type" of "text" (for example) would encompass the more
specific types of "book" and "poem". A very rough sketch:
text > (book, children's book, short story, poem)
video > (animation, stop motion, documentary, news reel)
Then, instead of roles being specific to a "book", they'd be
specific to a "text" type (thus, being inherited for short
stories, poems, and so on and so forth).
My current data model for LibDB has no way of storing these
"super-types", so I'll have to revisit it with that in mind.
From: PAT...@bn... on the FRBR list:
>To answer Morbus' question: I think that the institution that has=
developed
>the closes thing to what he needs is the AustLit Gateway Team. Do not
>hesitate to contact Kerry Kilner or Kent Fitch or Carol Hetherington on my
>behalf. They are subscribers of this listserv and can be contacted at
>fr...@nl.... But AustLit Gateway is only concerned with literary
>textual works, not with audiovisual materials. They have developed an
>authoritative list for:
>
>http://www.austlit.edu.au/common/manual/AuthorityLists.html#WorkTypeTerms
>http://www.austlit.edu.au/common/manual/AuthorityLists.html#FormTerms
>http://www.austlit.edu.au/common/manual/AuthorityLists.html#GenreTerms
From: Bruce D'Arcus <bd...@fa...> on the LibDB-develop list:
>http://www.loc.gov/marc/sourcecode/genre/genrelist.html
>http://www.loc.gov/marc/sourcecode/form/formlist.html
These URLs have been very helpful!
From a semantic standpoint, is there any consensus on terms here? Is
the "form" of a Work turning into a "super-type"? And is AustLit's
"Genre" really matches for the Group 3 Concept? And is MARC's
"Genre" the equivalent of the FRBR/CRM's "super-type"?
--=20
Morbus Iff ( you, me, eropuri? aawwwwwWWWw yYeahahhHHAhhh )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
|
|
From: Bruce D'A. <bd...@fa...> - 2004-07-23 12:45:07
|
On Jul 22, 2004, at 10:59 PM, Morbus Iff wrote: > The question: has anyone standardized on a set list of "form" types? I'm pretty sure "form" here is equivalent to "genre" in MARC/MODS (indeed, "form" strikes as a little strange here; see below). If yes, then your answer is both yes and no. In MODS, there is an authority attribute for stuff like genre terms. This basically says, look to controlled list x. Because such lists are community-specific, there can be no final all-encompassing list. The LoC has a genre term list that you can use as a start, though it's obviously more oriented towards books and such. http://www.loc.gov/marc/sourcecode/genre/genrelist.html You might see if there's a similar genre term list (for MARC, I guess) that cover movies. Note, though, there's another list for "form", which is the physical form: http://www.loc.gov/marc/sourcecode/form/formlist.html Bruce |
|
From: Morbus I. <mo...@di...> - 2004-07-23 02:59:16
|
This is a two part question. In a Work, we have an attribute "form":
"The class to which the Work belongs (e.g., novel, play, poem, biography,
symphony, concerto, map, drawing, photograph, movie script, etc.)."
The question: has anyone standardized on a set list of "form" types?
Anyone got a list of house rules they use? How is a "short story" of 4000
words different from a kid's "book" of 2000 words (assuming both have
some, or no, illustrations)? What if you've got a "photograph" of a
"drawing", and its the ONLY Manifestation of said "drawing"?
I ask because of "roles". "Roles" makes a very small appearance in the
FRBR spec, in 4.4.2 (the Manifestation's "statement of responsibility"):
"The statement may also indicate the role of function performed by
each of the individuals, groups, or organizations responsible."
In my LibDB project, "roles" are implemented on a much grander scale.
A "role" can be related to a person ("Director", "Writer", "Hair Stylist")
or a "corporate body" ("Distributor", "Special FX", "Insurance").
To start off the "roles" approach, I modeled a few movies based on data
from the IMDb. Within a short period of time, I had a listing of about
90 unique "roles" that can be attached to a Work of "form" "film" (or
"video"; I'm not sure which is better just yet, but "movie" has
been ruled out already for being too specific).
Showing these 90 "roles" in a dropdown menu (for example) is nice
and simple, IF the user is constantly adding "films" to their database.
However, if the user ever adds a "comic book" (for example), they have
to search through 90 (or more) unrelated "roles" to find the one they
care about ("Inker").
The solution was to assign certain "roles" to a specific Work "form",
such that you'd only see the 90 "film" "roles" if the user has previously
indicated that a Work is a "film". On the other hand, if the Work is a
"graphic novel" (a "form" that I'm using loosely to describe comics
and their inevitable collection-into-book-form), then they'd only
see ten or so different related "roles".
In some cases, "roles" would have no forced "form" - a "Writer" can
apply to most Work "forms" ("script", "comic", "film", "book", etc.).
The big problem with all this is having (or not having, in this case)
a collection of known Work "forms" that I can assign "roles" too. 99%
of "roles" assigned to a "book" would also be assigned to a "short
story", "poetry". They wouldn't necessary apply to "haiku".
Thoughts from the insanely quiet mailing list?
[Incidentally, there's a side note for you: if FRBR is so
great and magical, how come we're not talking about it?
Are people waiting for someone else to stun them with
an implementation, or is an objectified (as opposed to
E-R) approach the saving grace?]
--
Morbus Iff ( now in fun bath toy! )
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
|
|
From: <mo...@di...> - 2004-07-23 00:40:44
|
Project: LibDB Version: cvs Component: Documentation Category: tasks Priority: normal Assigned to: Anonymous Reported by: Morbus Iff Updated by: Little Nemo Status: active From the Directors Guild of Canada (of all places): Post Production Accountant(PPA) The Post Production Accountant is responsible for the coordination, supervision, and operation of the accounting department after principal photography has been completed. Little Nemo Previous comments: ------------------------------------------------------------------------ July 22, 2004 - 00:23 : Morbus Iff The provided libdb.mysql database schema contains a number of predefined role types, mostly from the film industry. Whilst most of them contain descriptions of what they actually entail, some are still missing. Those that are missing should be completed. ------------------------------------------------------------------------ July 23, 2004 - 00:34 : Little Nemo From filmsound.org: What is Audio Post-Production? ---------------------------------------------------------------------- Audio Post-Production is the process of creating the soundtrack for a visual program of some kind. Ever since silent movies began to talk, filmmakers have been looking to control and improve the quality of the sound of their creation. As soon as creators realized there was a way to control and enhance the sound of their pictures, Audio Post was born, and has been a fact of life ever since. In Television, audio was originally "live", like the visual program it was part of. As TV evolved, and the art form grew to include "videotaped" and "filmed" programming, the need for Audio Post increased. Nowadays, it would be difficult to find any feature film or television show that hasn't been through audio post. What is involved in Audio Post ? ---------------------------------------------------------------------- Audio Post usually consists of several processes. Each different project may need some, or all of these processes in order to be complete. The processes are: Production Dialogue Editing ADR (Automated Dialogue Replacement - if needed) Sound Effects Editing and Design Foley Recording (human sound effects recorded in sync with picture) Music Composition and Music Editing Mixing (also called re-recording) ------------------------------------------------------------------------ July 23, 2004 - 00:37 : Little Nemo From filmmusicmag: 3. What is an engineer (aka "scoring mixer") - A scoring mixer, also known as an engineer, works during the recording sessions to record and mix the music. The engineer is the primary technical resource at recording sessions, and oversees all technical aspects of the recording sessions. Scoring mixers work closely with composers and songwriters to make sure the recording process happens successfully, whether in a commercial studio or at a home project studio. Scoring mixers can also be a great source of technical information for composers and songwriters, providing up-to-date information about how current technology is used. -- View: http://drupal.org/node/view/9441 Edit: http://drupal.org/project/comments/add/9441 |
|
From: <mo...@di...> - 2004-07-23 00:37:56
|
Project: LibDB Version: cvs Component: Documentation Category: tasks Priority: normal Assigned to: Anonymous Reported by: Morbus Iff Updated by: Little Nemo Status: active From filmmusicmag: 3. What is an engineer (aka "scoring mixer") - A scoring mixer, also known as an engineer, works during the recording sessions to record and mix the music. The engineer is the primary technical resource at recording sessions, and oversees all technical aspects of the recording sessions. Scoring mixers work closely with composers and songwriters to make sure the recording process happens successfully, whether in a commercial studio or at a home project studio. Scoring mixers can also be a great source of technical information for composers and songwriters, providing up-to-date information about how current technology is used. Little Nemo Previous comments: ------------------------------------------------------------------------ July 22, 2004 - 00:23 : Morbus Iff The provided libdb.mysql database schema contains a number of predefined role types, mostly from the film industry. Whilst most of them contain descriptions of what they actually entail, some are still missing. Those that are missing should be completed. ------------------------------------------------------------------------ July 23, 2004 - 00:34 : Little Nemo From filmsound.org: What is Audio Post-Production? ---------------------------------------------------------------------- Audio Post-Production is the process of creating the soundtrack for a visual program of some kind. Ever since silent movies began to talk, filmmakers have been looking to control and improve the quality of the sound of their creation. As soon as creators realized there was a way to control and enhance the sound of their pictures, Audio Post was born, and has been a fact of life ever since. In Television, audio was originally "live", like the visual program it was part of. As TV evolved, and the art form grew to include "videotaped" and "filmed" programming, the need for Audio Post increased. Nowadays, it would be difficult to find any feature film or television show that hasn't been through audio post. What is involved in Audio Post ? ---------------------------------------------------------------------- Audio Post usually consists of several processes. Each different project may need some, or all of these processes in order to be complete. The processes are: Production Dialogue Editing ADR (Automated Dialogue Replacement - if needed) Sound Effects Editing and Design Foley Recording (human sound effects recorded in sync with picture) Music Composition and Music Editing Mixing (also called re-recording) -- View: http://drupal.org/node/view/9441 Edit: http://drupal.org/project/comments/add/9441 |
|
From: <mo...@di...> - 2004-07-23 00:34:49
|
Project: LibDB Version: cvs Component: Documentation Category: tasks Priority: normal Assigned to: Anonymous Reported by: Morbus Iff Updated by: Little Nemo Status: active From filmsound.org: What is Audio Post-Production? ---------------------------------------------------------------------- Audio Post-Production is the process of creating the soundtrack for a visual program of some kind. Ever since silent movies began to talk, filmmakers have been looking to control and improve the quality of the sound of their creation. As soon as creators realized there was a way to control and enhance the sound of their pictures, Audio Post was born, and has been a fact of life ever since. In Television, audio was originally "live", like the visual program it was part of. As TV evolved, and the art form grew to include "videotaped" and "filmed" programming, the need for Audio Post increased. Nowadays, it would be difficult to find any feature film or television show that hasn't been through audio post. What is involved in Audio Post ? ---------------------------------------------------------------------- Audio Post usually consists of several processes. Each different project may need some, or all of these processes in order to be complete. The processes are: Production Dialogue Editing ADR (Automated Dialogue Replacement - if needed) Sound Effects Editing and Design Foley Recording (human sound effects recorded in sync with picture) Music Composition and Music Editing Mixing (also called re-recording) Little Nemo Previous comments: ------------------------------------------------------------------------ July 22, 2004 - 00:23 : Morbus Iff The provided libdb.mysql database schema contains a number of predefined role types, mostly from the film industry. Whilst most of them contain descriptions of what they actually entail, some are still missing. Those that are missing should be completed. -- View: http://drupal.org/node/view/9441 Edit: http://drupal.org/project/comments/add/9441 |
|
From: <mo...@di...> - 2004-07-22 00:25:03
|
Project: LibDB Version: cvs Component: Documentation Category: tasks Priority: normal Assigned to: Anonymous Reported by: Morbus Iff Updated by: Morbus Iff Status: active The provided libdb.mysql database schema contains a number of predefined role types, mostly from the film industry. Whilst most of them contain descriptions of what they actually entail, some are still missing. Those that are missing should be completed. Morbus Iff -- View: http://drupal.org/node/view/9441 Edit: http://drupal.org/project/comments/add/9441 |
|
From: <mo...@di...> - 2004-07-22 00:22:57
|
Project: LibDB Version: cvs Component: User interface Category: tasks Priority: normal -Assigned to: Anonymous +Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff -Status: active +Status: closed Committed to CVS. Morbus Iff Previous comments: ------------------------------------------------------------------------ July 20, 2004 - 19:04 : Morbus Iff Our "data types" additions and edits really should be their own page, not at the bottom of the pager display pages (as large pager displays can cause the edit form to go below the fold, causing confusion). This'll require some new menu callbacks and all that crap, I suspect. Bollocks. -- View: http://drupal.org/node/view/9428 Edit: http://drupal.org/project/comments/add/9428 |
|
From: Morbus I. <mo...@di...> - 2004-07-20 19:52:42
|
>Not exactly: I mean a distinction between things issued once (a
>monograph, like a movie) and things issued continually at a regular
>interval (serials, like a TV show I guess, or a periodical).
Aaah. Check out "termination" in FRBR. From the Work data model:
termination: A reflection of whether the work has been conceived
as having a finite end or whether it is intended
to continue indefinitely.
--
Morbus Iff ( you, me, eropuri? aawwwwwWWWw yYeahahhHHAhhh )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
|
|
From: Bruce D'A. <bd...@fa...> - 2004-07-20 19:20:23
|
On Jul 20, 2004, at 3:08 PM, Morbus Iff wrote: > Are you talking about "frequency" of an issue, like yearly, or > monthly, that sorta thing? Not exactly: I mean a distinction between things issued once (a monograph, like a movie) and things issued continually at a regular interval (serials, like a TV show I guess, or a periodical). > I also haven't thought about handling of serials from an "issue" > standpoint - I have no current comments on reproducing "Vol. 12 > Iss. 13", "Vol. I, Issue VIII" or "December 2004, Holiday Special" > within the existing data model. This would be the part relationship stuff we discussed earlier. In MODS, there's an element within the relatedItem["host"] called "part" that captures these data (along with page numbers). Bruce |
|
From: Morbus I. <mo...@di...> - 2004-07-20 19:07:17
|
>> The following FRBR manifestation attributes have been ignored:
>
>FYI, much of this I don't care about. However, I probably do care
>about publication status (if that's covering the MODS' notion of
>"issuance" -- which includes "continuing" as in a serial, and
>"monographic") and numbering (though not quite sure what this is!).
I'm not sure that's what "publication status" is - my memory recalls
that loosely as a "yes, it's still being published", "no, it's dead",
or "unknown at this time" equivalent. Refer to the FRBR PDF for a
more technical description (and if my recollection is wrong,
certainly correct me).
Are you talking about "frequency" of an issue, like yearly, or
monthly, that sorta thing? In FRBR, this is defined at the
expression level, and is something also ignored in the
existing data model:
The following FRBR expression attributes have been ignored:
context, sequencing pattern (serial), expected regularity
of issue (serial), expected frequency of issue (serial) ...
The only real date work incorporated into the data model now
is libdb_events, which covers corporate bodies and their
meetings and so forth (from the data model notes on CB):
FRBR defines a "numerical designation sequencing a meeting,
conference, exhibition, fair, etc. that constitutes one of a
series of related meetings, conferences, exhibitions, fairs,
etc., or any other numerical designation associated with a
corporate body." These would be implemented as "events"
and associated with a "relationship".
Reference the libdb_events table for more information.
Briefly, it contains three date-related columns, thusly:
start_date: The date (YYYY-MM-DD) the event started.
end_date: The date (YYYY-MM-DD) the event ended.
frequency: How often the event occurs (e.g., yearly,
monthly, weekly, biannually, etc.).
As such, the following statements could
be made in the existing data model:
SerialA is type "serial", described in a WEMI model.
SerialA has relationship "publication status", which
maps to an entry (EventSerialsA) in libdb_events.
EventsSerialA defines a start_date of when the serial
started publishing, an end_date (possibly blank) of
when it ended, and a frequency of "quarterly", etc.
This, of course, is all off-the-top-of-my-head thinking - I've tried
to make the data model as flexible and "pure FRBR" as possible,
but I've only been thinking of it from an implementation standpoint
regarding movies/films, etc., etc. So, the above could all have
fatal flaws. I dunno yet. Haven't really thought about it.
I also haven't thought about handling of serials from an "issue"
standpoint - I have no current comments on reproducing "Vol. 12
Iss. 13", "Vol. I, Issue VIII" or "December 2004, Holiday Special"
within the existing data model.
--
Morbus Iff ( you, me, eropuri? aawwwwwWWWw yYeahahhHHAhhh )
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
|
|
From: Bruce D'A. <bd...@fa...> - 2004-07-20 18:42:13
|
Was just looking at the data model page. On this: > =95 The following FRBR manifestation attributes have been = ignored:=20 > typeface (printed book), type size (printed book), foliation=20 > (hand-printed book), collation (hand-printed book), publication status=20= > (serial), numbering (serial), playing speed (sound recording), groove=20= > width (sound recording), kind of cutting (sound recording), tape=20 > configuration (sound recording), kind of sound (sound recording),=20 > special reproduction characteristic (sound recording), reduction ratio=20= > (microform), polarity (microform or visual projection), generation=20 > (microform or visual projection), system requirements (electronic=20 > resource), file characteristics (electronic resource), mode of access=20= > (remote access electronic resource), access address (remote access=20 > electronic resource). They will be re-addressed later. FYI, much of this I don't care about. However, I probably do care=20 about publication status (if that's covering the MODS' notion of=20 "issuance" -- which includes "continuing" as in a serial, and=20 "monographic") and numbering (though not quite sure what this is!). Bruce |
|
From: Richard A. <lil...@ya...> - 2004-04-20 01:46:06
|
>Morbus wrote: >In 99% of the cases I can think of, an identifier is related to a >manifestation. ISBNs, ISSNs, DOIs, UPC's, Amazon ASINs, etc., etc. >I haven't had any problem coming to this conclusion: identifiers >should relate to the physical manifestation of the expression. > >Except... when it comes to an IMDb identifier.... >But IMDb doesn't talk about physical manifestations of movies, it >talks about the movies themselves: in other words, the expression. >The IMDb identifier should be related to the expression. > >Does this make sense? How are other people handling identifiers? >Can anyone think of similar identifiers that are better to an >expression than a manifestation? I have been following the LibDB project, but have little actual knowledge of programming or FRBR for that matter. Having said that, I won't let it keep me from giving my 2 cents. The interface will essentially dictate that the owner/cataloguer physically handle the item and enter all works, expressions, and manifestations correct? Okay, now, after the initial data entry the other identifiers mentioned (ISBNs, ISSNs, etc) will allow said person to readily identify a given manifestation of an expression so as to either: a.Locate a physical copy b.Cross-reference it with another work, expression, or manifestation. c.Replace a lost copy of a manifestation with an exact copy. Any other identifier (IMDB, MusicBrainz ID) would allow one to reference information that is already entered in LibDB(?). I say keep these "extra" identifiers with the expression, or in the case of ArtistID's (MusicBrainz example: http://musicbrainz.org/artist/83d91898-7763-47d7-b03b-b92132375c47.html)with the person or (corporate) body. __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash |
|
From: Morbus I. <mo...@di...> - 2004-02-26 20:35:12
|
>Re: http://justlooking.recursion.org/2004/Feb/19 >I like your "New Window" thing better, and I'm glad you linked to >QBullets - I've actually been thinking about iconography for my >latest project (http://disobey.com/noos/LibDB/). Part of my problem, >however, is size. > > * To use QBullets, you must place them AFTER the link. This > causes people to have to *look* for the icon, not to expect > it in a semi-standard place (like on the left side of a title): > http://disobey.com/noos/LibDB/dev/admin.cgi?tmpl=locations > > * Even with the icons in a relatively standard, not-determined- > by-amount-of-content location, they still seem awfully small. > I can't imagine myself trying to pinpoint my mouse on such > a small little icon, day-in and day-out. I've already had > problems with that testing my own interface (above, though, > part of my problem is their proximity to a different type > of link that is much much bigger). -- Morbus Iff ( i put the demon back in codemonkey ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
|
From: Morbus I. <mo...@di...> - 2004-02-22 03:38:42
|
>This is a reasonable conclusion to come to. Indeed the MODS developers >came to the same conclusion initially as well. But then I and a >couple of other people pointed out that a uri is a location too; or at >least it can be thought of in such a way. A DOI is an identifier that >can resolve to a location (a url), is how I'd tend to think of it. Quite true, but they're identifiers first - they're "higher" in the hierarchy of intent (DOI to URL, URI to URL). Just because they *eventually* resolve to a location shouldn't classify them as locations, anymore that an Amazon ASIN (which is ONLY accessible via a URL/location) should be considered a location *more* than an identifier. Ultimately, with the Internet, *any* identifier shares the same property as an electronic asset: an ISBN can be resolved into a URL/location at ISBN.nu, UPCs are being stored in upcdatabase.com, etc., etc. -- Morbus Iff ( sleep breeds sanity ) 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 |
|
From: Bruce D'A. <bd...@fa...> - 2004-02-22 03:21:43
|
On Feb 21, 2004, at 9:13 PM, Morbus Iff wrote: > I'm inclined to say "an electronic resource has an /identifier/ like a > DOI or URI, and not a /location/". This is a reasonable conclusion to come to. Indeed the MODS developers came to the same conclusion initially as well. But then I and a couple of other people pointed out that a uri is a location too; or at least it can be thought of in such a way. A DOI is an identifier that can resolve to a location (a url), is how I'd tend to think of it. Still, I agree this isn't anything critical now. I'm just throwing these ideas out there for you to consider now; not necessarily to resolve them all at once... Bruce |
|
From: Morbus I. <mo...@di...> - 2004-02-22 02:22:35
|
>At minimum, the ability to distinguish physical locations (.e.g
>archival holding locations) from electronic. For electronic,
>citations require date accessed info.
>
> Collection X, ABC Archive, Box 23, Folder 324
>
>...the collection info is actually a title associated with the isPartOf
>(or mods relatedItem "host") structure, so that's no big deal. Beyond
>that, I actually have three further chunks of information. But then
>... is the archive really a location, or should it be handled by some
>other structure? Box and folder are two separate location
>designations, but then this starts to become blurred with another
>structure: "parts" in MODS, which represent things like page, volume
>and issue numbers. Where's the conceptual line between a folder and an
>issue, after all? Maybe a distinction between an, um, manifestation
>and an item??
Well, I'm not thinking of "location" as anything like "parts" of an
item. Sure, an article has a "location" within a magazine, but that's
not what I want LibDB's "location" to mean. Or rather, that's not what
I *intend* it to mean. In the current scheme, "location" solely means
"where an item is physically located" - a box, a shelf, a bookcase.
The current location scheme doesn't support hierarchies either, so
if you wanted to indicate multiple levels of granularity, it'd have
to be a single name ("Collection X, ABC Archive, Box 23, Folder 324")
mainly because the current assumption is that *one* item can only
have *one* location. Granted, we can go nuts with specifics:
"North America, United States, New Hampshire, Concord, 28 Thompson
St., Apt. A, Collection X, ABC Archive, Box 23, Folder 324" could
point to the exact same location as "Folder 324" (assuming I had
only one "Folder 324" in my collection).
I don't want, from the beginning, to overcomplicate what I'm doing.
I *really* need to say "mmkay, this is what I'm coding, and anything
extra will be dealt with later." Else the standard feeping creaturism
stuff happens: always building with never a release. With that in mind,
I'm not sure that 0.1.0, or even 0.2.0 and 0.3.0, is going to be usable
from an *electronic resource* point of view: for now, I'm strictly
focusing on physical assets, and even narrower, movies (and even
narrower, physical representations of movies, not encoded digital).
Still, I can't help but feel that an electronic resource should not
be labeled with a "location" but rather as having an identifier that
points to a location. This seems to be a core idea of the DOI project:
give an electronic resource an identifier, and DOI servers will take
that identifier and give you a location. Without further research (and
I'll heartily admit that I've NOT done heavy resource on cataloging
electronic assets), I'm inclined to say "an electronic resource has
an /identifier/ like a DOI or URI, and not a /location/".
--
Morbus Iff ( whooooooo's hoooouuuuuse? )
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
|
|
From: Bruce D'A. <bd...@fa...> - 2004-02-21 03:49:57
|
On Feb 20, 2004, at 10:54 AM, Morbus Iff wrote: > >> From an "FRBR model" standpoint, it really doesn't. FRBR mentions > that > >> an item is located somewhere, but it doesn't set out to > conceptualize > >> "location" as anything but a relationship/attribute. > > > >Which is a problem in the real world. Clearly the FRBR is a > >meta-model; it solely defines broad structures. But implementations > >need to sort out these details. I'm not exactly sure how to deal with > >this, but I get the feeling there's an elegant way to do just that. > > Welp, what are your requirements for a "location"? At minimum, the ability to distinguish physical locations (.e.g archival holding locations) from electronic. For electronic, citations require date accessed info. Beyond that, I've noted this awkwardness on the MODS list. In this example (only quasi-hypothetical): Collection X, ABC Archive, Box 23, Folder 324 ...the collection info is actually a title associated with the isPartOf (or mods relatedItem "host") structure, so that's no big deal. Beyond that, I actually have three further chunks of information. But then ... is the archive really a location, or should it be handled by some other structure? Box and folder are two separate location designations, but then this starts to become blurred with another structure: "parts" in MODS, which represent things like page, volume and issue numbers. Where's the conceptual line between a folder and an issue, after all? Maybe a distinction between an, um, manifestation and an item?? Ugh, am rambling... Bruce |
|
From: Morbus I. <mo...@di...> - 2004-02-20 16:21:22
|
Impromptu discussion of FRBR/LibDB on irc.freenode.net. When I'm there, I'm always in #disobey and #swhack. The unedited form is archived permanently at the following URI: http://notabug.com/swhack/chatlogs/2004-02-20.html#T15-27-44 --- <deltab> you noted that users would differ in how strictly they'd apply rules, how much they'd learn of ontologies, etc. <Morbus> correct, yes. <deltab> it might be a good idea to store what class of user enters data <Morbus> so that then upper levels would be able to say "show me data from people who know what they're doing"? <Morbus> deltab: so, you want that lvl applied to rows, not the whole db? rows would be the only way to say "show me something to fix". <deltab> yes --- <deltab> did you notice the section in FRBR about parts? <Morbus> i've noticed the section on parts, but I don't remember it 100%. my impression on the first read through was that it was related to individual physical parts of a whole: the study guide to an english book, the troika in a music CD, etc. the parts that have been discussed on the list have been related to parts of a singular item. pg 3 through 7, minutes 6:43 to 6:59, etc. i didn't think the frbr parts dialog covered that stuff. but, again, i don't recall specifics. i've done no specific coding or development work on "parts" as a concept. <deltab> me neither. I wanted to read that section again <Morbus> i wanted to read a bunch of stuff about movie encoding too before i did any "real" thoughtwork on it. er, not movie encoding per se, but movie markup related stuff. i've a document somewhere that talks about movie metadata. <deltab> you're not daunted by the potential massive scale of it? so many people, so many pieces of work assembled <Morbus> not really. i know what i want, and i strive to get it. well, yeah, i mean, the amount of reading to be done sucks. especially considering that no one can agree on anything. but, i'm equally positive that whatever choice i make, a bunch of people are gonna say "you should use my idea instead". --- <deltab> have you decided exactly what will be described and what won't? <Morbus> ultimately, its up to the end-user, but i've modeled one of my own movies in the mysql_sample.sql the movie in the sample schema models production companies, hair and makeup assistances, and defines objects on a lievel like "swimwear". it also keeps track of the characters played by a person, and the artisan (distribution company) catalog number. i certainly don't expect "casual" users to care about that stuff. and i have no doubt that librarians aren't gonna give a crap about the "artisan catalog number". <Morbus> how much you put in is really up to you. but the data that i've been building around as my base assumes a high level of detail. personally, for mem, i'm gonna be marking up how people die in a movie. so, my personal LibDB will include a "Death By" annotation. which will be searched/indexed/shown along with all the other annotations, etc. you'll be able to show all "death by garden tools" in "films" of the "1980s", for instance. <deltab> I suppose even something like Darth Maul's contact lenses could be considered works, <Morbus> well, the user could do that if they wanted. i'm certainly not going to stop them. but it doesn't make any goddamn sense. <deltab> it might for the designer :-) <Morbus> it doesn't fit well in the frbr model, and it doesn't have any true identifiers (unless you consider retail model number duplicates, patent numbers, etc.) but, yeah, if you wanted to make a contact lense database, sorted by color (concepts), objects (stars, spirals, cats eye), or event (halloween, swimming), you could do that. <deltab> and have them connected to the films in which they're used? <Morbus> deltab: yes, because you'd be able to define a) relationship types ("ie. film prop") and b) relationship ("this WORK is a FILMPROP of WORK") <deltab> so it could get arbitrarily complex nice in theory, but could chew up lots of time <Morbus> yes. the user determines how complex. [chewing up lots of time] doesn't sound any different from any other metadata-galore system though. i think the only people who would truly *use* *use* the metadata system would be the second level of user. the first (casual) user wouldn't want to put that much effort in. the third (librarian) wouldn't have TIME to put that much effort in. so only the second (discriminating) user would attempt to. but, that's not to say that it won't be possible for the other users. --- <sbp> so it'd be nice if you could search within the labels that you put in. will you allow that? so all deaths that contain the word "garden", etc. <Morbus> sbp; yes, that'd be possible. annotations can be searched by. i don't have any plans (yet) to make a topic map interface, but the db supports it. a concept can have a relationship to another concept. so, the "Rake" object could be a RT to the "Garden Tool" object. you'd then be able to browse objects, concepts, places, etc., in a hierarchal sense. or, show related terms on searches, in listings, etc. --- Thoughts? -- Kevin Hemenway |
|
From: Morbus I. <mo...@di...> - 2004-02-20 16:01:43
|
>it is analogous to how MODS deals with locations: > ><location> > <physicalLocation>whatever</physicalLocation> ></location> > ><location> > <url dateLastAccessed="2003-10-21">http://www.example</url> ></location> > >Is that right? (Note, though: MODS doesn't actually have such an >attribute, but it does have "authority" and "displayLabel", which could >be used for this sort of thing) In essence, yes (though, I'm not sure how I'd represent dLA). The MODS exporter of LibDB would have to be hardcoded to *know* that a URI identifier belongs as a <url> <location> though. That's not too worrisome though, because any sort of conversion format has to know about to/from in a hardcoded sorta way. >> From an "FRBR model" standpoint, it really doesn't. FRBR mentions that >> an item is located somewhere, but it doesn't set out to conceptualize >> "location" as anything but a relationship/attribute. > >Which is a problem in the real world. Clearly the FRBR is a >meta-model; it solely defines broad structures. But implementations >need to sort out these details. I'm not exactly sure how to deal with >this, but I get the feeling there's an elegant way to do just that. Welp, what are your requirements for a "location"? -- Morbus Iff ( i put the demon back in codemonkey ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
|
From: Bruce D'A. <bd...@fa...> - 2004-02-20 15:37:52
|
On Feb 20, 2004, at 9:51 AM, Morbus Iff wrote:
> Would that work for you?
If I understand what you are saying, it is analogous to how MODS deals
with locations:
<location>
<physicalLocation>whatever</physicalLocation>
</location>
<location>
<url
dateLastAccessed="2003-10-21">http://www.example.net/test.xml</url>
</location>
So if you were to represent your video shelf in XML, it might well be:
<location>
<physicalLocation type="shelf">whatever</physicalLocation>
</location>
Is that right? (Note, though: MODS doesn't actually have such an
attribute, but it does have "authority" and "displayLabel", which could
be used for this sort of thing)
> >So what is a location? Say I want to store a bunch of records from an
> >archival collection. So: ABC Archive, Collection X, Box 23, Folder 324
> >How does this fit in the model?
>
> From an "FRBR model" standpoint, it really doesn't. FRBR mentions that
> an item is located somewhere, but it doesn't set out to conceptualize
> "location" as anything but a relationship/attribute.
Which is a problem in the real world. Clearly the FRBR is a
meta-model; it solely defines broad structures. But implementations
need to sort out these details. I'm not exactly sure how to deal with
this, but I get the feeling there's an elegant way to do just that.
Gotta go...
Bruce
|
|
From: Morbus I. <mo...@di...> - 2004-02-20 15:00:32
|
>Yeah, the current focus of LibDB is physical materials. I haven't >given digital material much thought, but you could do the following >in the current system and it'd work well enough (in fact, I'm jotting >down a note to include "URI" as a default annotation): > > * define a location called "Online" (or some such). locations > are solely relationships: besides describing a location type, > you can't add *per-item* metadata to them. but... > > * define an annotation called "URI". annotations are defined > as relationships too, but you can add as many strings per > annotation type per item as you want. they have nothing to > do with locations, so ultimately, you could leave the location > of an item blank, and just use the "URI" annotation. > >With the above, you could have: > > Location Type: Online > Annotation Type: URI > > Title: Online Newspaper Record > Location: [Location Type: Online; no value, relationship only.] > Annotation: [Annotation Type: URI; Value: "http://www.demo.com/"] > Annotation: [Annotation Type: URI; Value: "http://www2.demo.com/"] > Annotation: [Annotation Type: URI; Value: "http://bak.offsite.com/"] Replace "annotation" with "identifier". URIs are identifiers. -- Morbus Iff ( i put the demon back in codemonkey ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
