On Wed, November 17, 2010 5:37 pm, Jonathan Rochkind wrote: > I agree entirely with your analysis, Lee, but am still confused about your > objection to assigning a Work a title!
I'm not strenuously opposed to assigning a title to a work, no more so than say assigning a cover image to a work, or a "first publication date" property. I just don't find any of that data appropriate or useful, so when I'm processing a data stream that includes these properties I just discard them. Before going any further, let me expose my bias. I am first and foremost interested in machine processing of data, and developing methods where the data can be shared among multiple, disparate systems. Building a nice user interface to expose the data to a human being is, for me, a secondary concern. Generally I have found that it is far easier to build a human interface from a conceptually clean machine interface than the reverse. OpenLibrary has taken the second approach and, as I'm sure you've discovered, trying to make sense of an OL data dump is a PITA. > Doesn't one, in some circumstances and applications, sometimes need to > present a Work to users as a result on a screen? Yes. > How is it to be labelled? However it makes sense in the context of the presentation. > Why is it inappropriate for the Work entity to contain a title (or really, you > are quite right, no reason to only insist on ONE title, perhaps multiple), > that can be used by the application, when convenient/useful to do so, to label > the Work group? For purposes of machine processing, a Work entity needs an identifier which is at least locally unique; this is how we build relationships from Expressions. If the data is going to be transfered to another system that identifier needs to be globally unique as well (source institution + locally unique identifier may satisfy that need, but may not facilitate merging of data). If the Work's title can satisfy that need, great. If it cannot, I have a hard time coming up with a use in machine processing. For purposes of presentation to humans, my preferred method of displaying a Work's title would be to scan my database for all Expressions having an 'expressionOf' value equal to the work identifier and then present all unique titles from the resulting collection of Expressions. If TPTB mandate that I could only display a single title I would scan my collection of expressions a select a.) the oldest "expressedOn" date or b.) the first expression that was inserted into my database. If TPTB mandate that the singular title to be displayed is whatever title they happen to want, I would create a /new/ Entity called "Locally Preferred Options." This new entity would hold a references to a Work and the Expression of that work whose title is the locally preferred title. Alternatively it could hold a string property which would be the display title for the Work entity independent of /any/ known expressions. It could hold any other locally preferred data as well, such as the cover image of a manifest ion representative of the work to display, or shelving instructions for items. The important notion here is that all of these Locally Preferred Options are, by definition and intent, local. If you send me a Work record that has a 'title' property, and that property is not a unique identifier of some kind, all I can conclude is "here is some data that Mr. Rochkind thought was meaningful in the context of his system based upon considerations that may or may not match my own." From a machine processing perspective I might be inclined to carry that data around in a free-form, unqualified 'Other Distinguishing Characteristics' field, but /I/ can't make use of it because it has no significance outside of your local environment. >From an automated data processing perspective I would prefer it if all FRBR representations limited themselves to a controlled set of properties having a known syntax and global meaning. Local data can be useful, but should be exposed outside of the FRBR schema. If you want to include local data in your WEMI entities that's really not a problem; having too much data is better than having too little. But it's important to remember that the data /is/ local, and may very well be lost as the containing record is transmitted and transformed. _______________________________________________ Ol-tech mailing list [email protected] http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech To unsubscribe from this mailing list, send email to [email protected]
