Thanks, Nate. That tool will be extremely helpful. I think my confusion
stems largely from the fact that these MARC >> BIBFRAME records and other
BIBFRAME records I've seen are just meant to be ingested into a catalog
system and are not meant to be used as actual URI endpoints. Since we are
digitizing unique collections, the records I am trying to create will be
canonical for these digital resources and are meant to live on the open web
as endpoints rather than just being indexed internally within an ILS. For
instance, the URL
http://lx2.loc.gov:210/LCDB?query=rec.id=5226&recordSchema=bibframe2a&maximumRecords=1
contains both Work and Instance nodes at the top level of the RDF graph.
My (naive, limited) understanding of linked data is that one URI is
supposed to represent one Thing. I just want to make sure I am not
committing an error by deciding that Thing is a Work with Instance and Item
blank nodes as children rather than having three separate Things for Work,
Instance, and Item with three separate URIs. Does my question even make
sense?
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 11:38 AM, Trail, Nate <[log in to unmask]> wrote:
> LC has implemented a converter from marc using its SRU site:
>
> http://lx2.loc.gov:210/LCDB?query=rec.id=5226&recordSchema=bibframe2a&
> maximumRecords=1
>
> This is a full package that would include some duplications of data
> because of that conversion, and does not have a base uri to mint unique
> uris for each part, so it's all "blank nodes" until you do something with
> it.
>
>
>
> We also have a comparison tool to show the descriptions side by side with
> their marc counterpart; you can enter any bib id or lccn in the LC catalog
> to see what it converts as.
>
>
>
> http://id.loc.gov/tools/bibframe/compare-id/full-ttl
>
>
>
> You should certainly have uris for the Works, Instances, and Items, and
> the blank nodes we've created help you keep them unique within a
> description (http://bibframe.example.org/5226#Topic650-22 represents the
> 12th xml element and it's based on the marc tag 650 in the old record).
>
> However,
>
> <http://bibframe.example.org/5226#Topic650-22> a bf:Topic,
>
> madsrdf:ComplexSubject ;
>
> rdfs:label "Wheels--Fiction." ; ….
>
>
>
> is not unique necessarily in any database you are inserting this into, so
> there is some deduplication that has to happen on ingest to a triplestore,
> or lookup to an authority to replace .
>
> When you use the “bibframe2a” recordSchema in our metaproxy/SRU (see
> above), there is some lookup to the id.loc.gov label services for names,
> subjects, and a few more nodes, to remove some of that duplication.
>
> So Wheels—Fiction does not (yet) have it’s own uri and you’ll need to
> handle that, but Miniature books does, so the blank node construct is
> replace by the subject uri at id:
>
> <http://id.loc.gov/authorities/subjects/sh85085643> a bf:Topic,
> madsrdf:Topic ;
> rdfs:label "Miniature books." ; …
>
>
>
> I think whether you are using rdfxml (which is hierarchical by nature) for
> the BIBFRAME descriptions lends itself to the nested approach you have in
> 1). But the non-nested approach works just as well, even in rdfxml; you
> will always have the linking properties hasInstance or instanceOf that help
> you traverse the graph. Just for sanity it might help to tag a whole
> description as a graph so you can operate on the whole package later (as
> long as subsequent edits/additions are in the graph as well).
>
>
>
>
>
> Nate
>
>
>
> -----------------------------------------
>
> Nate Trail
>
> Network Development & MARC Standards Office
>
> LS/ABA/NDMSO
>
> LA308, Mail Stop 4402
>
> Library of Congress
>
> Washington DC 20540
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Josh Welker
> Sent: Thursday, January 18, 2018 12:08 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] BIBFRAME nesting question
>
>
>
> I guess I am trying to figure out what the well-defined view looks like. I
> can't find examples that contain Work, Instance, and Item within the same
> RDF document at the same URI. In fact, the examples section on the LC
> BIBFRAME 2.0 website is blank, and the links for BIBFRAME 1.0 are all dead.
>
> I certainly am not trying to reinvent anything, which is why I am posting
> here.
>
>
>
> 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 11:00 AM, McDonald, Stephen <
> [log in to unmask]<mailto:[log in to unmask]>> wrote:
>
>
>
> > BibFrame already has an RDF view which is well-defined. Are you
>
> > trying to come up with your own RDF model for BibFrame data?
>
> >
>
> > Steve McDonald
>
> > [log in to unmask]<mailto:
> [log in to unmask]>
>
> >
>
> >
>
> > -----Original Message-----
>
> > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
>
> > Josh Welker
>
> > Sent: Thursday, January 18, 2018 11:28 AM
>
> > To: [log in to unmask]<mailto:[log in to unmask]>
>
> > Subject: [CODE4LIB] BIBFRAME nesting question
>
> >
>
> > Hi all,
>
> >
>
> > I have a question about how to model a resource expressed in BIBFRAME.
>
> > We are digitizing some unique collections. Ideally, I'd like to have
>
> > one URI like http://example.org/myuri that returns one RDF document
>
> > containing data about the Work, the Instance, and the Item. There are
>
> > two ways I could do
>
> > this:
>
> >
>
> > 1. Use Work as the parent type and include the Instance as a child
>
> > blank node using the Work.expressionOf property, and then include the
>
> > Item as a second-level child node using the Instance.hasItem property.
> Example:
>
> >
>
> > bf:Work:
>
> > bf:title: [title node here]
>
> > bf:hasInstance:
>
> > bf:Instance:
>
> > bf:bookFormat: [bookFormat node here]
>
> > bf:hasItem:
>
> > bf:Item:
>
> > bf:shelfMarker: [shelfMarker node here]
>
> >
>
> >
>
> > 2. Use some parent container class like rdf:Description and include
>
> > the Work, Instance, and item as immediate children blank nodes of that
>
> > container. Example:
>
> >
>
> > rdf:Description:
>
> > bf:Work:
>
> > bf:title: [title node here]
>
> > bf:Instance:
>
> > bf:bookFormat: [bookFormat node here]
>
> > bf:Item
>
> > bf:shelfMarker: [shelfMarker node here]
>
> >
>
> >
>
> > 3. If neither 1 nor 2 are acceptable, I could have separate URI
>
> > endpoints for the Work, Instance, and Item. This has the advantage of
>
> > using less blank nodes:
>
> >
>
> > http://example.org/myuri_Work
>
> > http://example.org/myuri_Instance
>
> > http://example.org/myuri_Item
>
> >
>
> > I really prefer option 3 the least, but I am very uncertain between 1
>
> > and 2. Thoughts on which is best practice? If 2, what should I use as
>
> > the container class? And in any case, how much should I worry about
>
> > the proliferation of blank nodes?
>
> >
>
> > Joshua Welker
>
> > Information Technology Librarian
>
> > James C. Kirkpatrick Library
>
> > University of Central Missouri
>
> > Warrensburg, MO 64093
>
> > JCKL 2260
>
> > 660.543.8022
>
> >
>
|
