 |
 |
On Thu, Jan 18, 2018 at 11:49 AM, Karen Coyle <[log in to unmask]> wrote: > My gut feeling is that you should analyze your own data based on your > own use cases and then posit a model - so that your ideas are clear > before you step into the morass of BF assumptions... This. On Thu, Jan 18, 2018 at 11:53 AM, Jonathan Rochkind <[log in to unmask]> wrote: > .... I'm not sure how > much BF is really going to tell you. I'm also not sure if at present being > "BibFrame-compliant" actually does anything for you. > And this. Calling something "BibFrame compliant" is like calling it "MARC compliant." Being able to read/generate data and doing something useful are totally different things -- the meaning rather than the structure of the data is what is important. You can think about this like planning a grocery store -- helping people find things to satisfy their hunger for food is similar to helping them satisfy their hunger for knowledge. A good grocer thinks about what s/he has and can get, what people need, and how to arrange things to meet those needs most effectively. Customers expect pickles by the ketchup rather than the cucumbers or vinegar which are in totally different areas of the store. They expect salsa by the refried beans and nowhere near ketchup or tomato sauce (which are also in completely separate areas). A weird grocer thinks abstractly about UPC codes (which are technically URIs), builds an organizational scheme around that, and then describes peoples' needs in terms of that architecture. Sadly, too much bibliographic modeling is like that. kyle