Thanks, Nate. Can you say whether the BIBFRAME Editor will follow this pattern as well? I believe the beta version currently outputs a resource with URI for every entity, including Provider et al.

Tim


On Thu, Apr 23, 2015 at 10:18 AM, Trail, Nate <[log in to unmask]> wrote:

Tim, good question. I think it’s a question  of re-use or use-cases. For example, what’s the utility of a re-usable Provider node like  “Naperville, Ill. : Sourcebooks, c2008.” How many times would that  publication event ever be re-used? We should make efforts to turn Naperville, Ill,  into a uri pointing to the Place,yes. It would also be nice if there were a uri out there for all imprints/publishers/distributors, so we could point to “example.org/Sourcebooks” or whatever, but there isn’t , yet, and the data isn’t clean enough to actually know what to do with it. So for now we’ve just been keeping the data in a node by itself, and trying to wrap multiple places, pubs,distributors in separate blocks to facilitate downstream cleanup.

 

Identifiers would be great to have as uris, but there just aren’t rdf resources that resolve them, unless/until we put them  up ourselves. (We do have plans to add more of this sort of stuff at id, but we shouldn’t be in the business of adding issn resolvers, for example; those are not our numbers.)

 

Bf:Title being flattened out may be a mistake; I think it should really just a blank node, too.  I don’t much like blank nodes, but we need to group together the title properties.  Is there a use-case for  having all the bf:Works with the title “[Untitled] Photograph 1991.” point to a single resource someplace that returns you that string when you(r system) reference it?

 

Nate

 

-----------------------------------------

Nate Trail

Network Development & MARC Standards Office

LS/ABA/NDMSO

LA308, Mail Stop 4402

Library of Congress

Washington DC 20540

 

 

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Tim Thompson
Sent: Wednesday, April 22, 2015 5:42 PM
To: [log in to unmask]
Subject: [BIBFRAME] Blank nodes vs. resources (redux)

 

All,

I've been working with the "flat" RDF/XML output from LC's marc2bibframe scripts, and I'd like to understand a little better why some things have been modeled as blank nodes, whereas others have been presented as separate resources.

For example, bf:Provider and bf:Identifier are blank nodes, but bf:Title is a separate resource with its own URI. Why not make everything a resource? Or is there a good reason for keeping some things as blank nodes, in terms of querying, modeling, etc.? I know this ground has been tread before, but I'd like to come at it from the perspective of integrating newly created BF data with BF data that has been converted from MARC. Greater clarity about the way resources are being modeled, in this regard, would help facilitate production workflows moving forward.

Tim


--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library
https://listserv.loc.gov/cgi-bin/wa?A3=ind1504&L=BIBFRAME&E=quoted-printable&P=2367600&B=--001a11c2ee9e2246cb05147cc406&T=text%2Fhtml;%20charset=UTF-8&pending=
listserv.loc.gov
crawl=CC-MAIN-2022-33
7143
application/http; msgtype=response
sha1:5BPEFNTPXQ2KNG7JQTDADFYOJVTCT57B
<urn:uuid:18000c7d-ab32-4be4-8223-89fecff63843>
2022-08-10T11:26:19Z
140.147.239.86
text/html
sha1:H3CC6PN3Q634IXCSRGWLKNZLXDVQHJH4
<urn:uuid:e511bd40-6db4-4398-873a-9df3cd4f54fe>
https://listserv.loc.gov/cgi-bin/wa?A3=ind1504&L=BIBFRAME&E=quoted-printable&P=2367600&B=--001a11c2ee9e2246cb05147cc406&T=text%2Fhtml;%20charset=UTF-8&pending=
response
<urn:uuid:afe8ebee-a8ed-4c10-b2c1-84bd2c67e061>
isPartOf: CC-MAIN-2022-33
publisher: Common Crawl
description: Wide crawl of the web for August 2022
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-112
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.4-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/