>
> 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.



Very helpful analogy, but it breaks down at a point. In a grocery store,
you know exactly who your customers are and some basic approximation of
what they want. In the case of RDF data, your "customer" is essentially
everyone on the Internet. And with BIBFRAME in particular, the "customers"
that will consume BF datasets don't even exist yet. So it's more like a
grocer trying to organize his store to best serve Martians who will be
arriving in 2030.

After some reading and discussion, it seems like BIBFRAME has two very
separate use cases that appeal to different people:

   1. A way to store MARC data in a more machine-readable format to be used
   within library systems like an ILS or discovery system.
   2. A way to classify linked data that is exposed to the open web.

There are a good number of examples for use case #1 but virtually nothing
for #2. Unfortunately, #2 is what I am trying to accomplish. I am looking
for best practices in a domain where no one is even practicing, let alone
"best." Since my guess seems to be as valid as anyone else's, once I throw
something together I will ask for feedback. It's just surprising to me
because I essentially just want to publish institutional repository
metadata using BF, and I assumed before starting the project that surely
there was some established model for doing so.

Joshua Welker
Information Technology Librarian
James C. Kirkpatrick Library
University of Central Missouri
Warrensburg, MO 64093
JCKL 2260
660.543.8022


On Thu, Jan 18, 2018 at 4:00 PM, Kyle Banerjee <[log in to unmask]>
wrote:

> 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
>