LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  September 2013

BIBFRAME September 2013

Subject:

Re: What used to be uniform titles

From:

Jörg Prante <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Mon, 2 Sep 2013 10:48:20 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (188 lines)

What I don't see is that all kinds of protocols are neutral to Bibframe. 
Bibframe is a web-based technology and won't work with non-web 
protocols. I think the Bibframe model embraces the web and should really 
deal with dependant information about resources on the semantic web, 
including protocols and serialization formats. For example, cool URIs 
http://www.w3.org/TR/cooluris/ or URI dereferencing 
http://www.w3.org/wiki/DereferenceURI just a name very few and very 
basic principles.

But it's a misconception if each and every access from all over the 
internet to an LoC authoritative resource on the semantic web would have 
to go over the wire and access the id.loc gov server. Endorsing only a 
specific solution would not help here. There are many network 
architectural solutions to prevent bottleneck situations. A simple 
implicit cache is just one of them, but even simple solutions can not be 
assumed to be available to Bibframe user environments by default.

My view of Bibframe is not being just a target behind the curtain which 
gathers only from authoritative sources and never is exposed directly 
again, like MARC was. Bibframe should serve as a vehicle to establish 
interactive catalog data transport over the open web, from library to 
library, and from and to external communities, but with third party 
implementations of choice.

So to make this choice possible, I think the Bibframe specification 
could be improved if it got accompanied by an implementation guideline, 
giving some ideas about what has to be considered in addition to the 
model to become a resilient Bibframe implementation.

Jörg

Am 01.09.2013 12:38, schrieb Rurik Greenall:
> Yes.
>
> I entirely agree with Richard here.
>
> Rurik.
>
>
> On Sep 1, 2013, at 12:21 PM, Wallis,Richard wrote:
>
>> The architecture of the web and the RDF/Linked Data principles, we 
>> are attempting to apply and build upon in BIBFRAME, makes significant 
>> implicit use of caching (your web browser does it by default, your 
>> organisation probably caches all your incoming web traffic).
>>
>> If applied correctly it allows you to a) Treat an authoritative 
>> service (e.g. VIAF, LCSH, LC, etc.) as a live source of truth.  b) Be 
>> insulated from network failure/performance issues. c) Not have to 
>> build & maintain complex sync/batch load processes locally. d) Use 
>> widely available general purpose, often open source, tools to achieve 
>> this.
>>
>> There may well be the need to build local indexes for external 
>> sources/resources, but use the architecture of the web to get the 
>> data, don't over complicate a new data model with protocol dependant 
>> information which will only serve to confuse implementers further 
>> down the line.
>>
>> BIBFRAME should concern itself with the data, and the associated 
>> model & vocabulary, to describe resources without constraining itself 
>> with serialisation formats (XML, Turtle, JSON, etc.) or communication 
>> protocols (http, OAI-PMH, ResourceSync, ftp, etc., etc.)
>>
>> ~Richard
>>
>>
>>
>> On 1 Sep 2013, at 08:21, Shlomo Sanders 
>> <[log in to unmask] 
>> <mailto:[log in to unmask]>> wrote:
>>
>>> Caching locally may be practical if a protocol like ResourceSync is 
>>> publically endorsed and included in BF.
>>> This protocol is much more powerful than OAI-PMH which is the only 
>>> protocol current mentioned in the BF documents.
>>> In the document where it is mentioned some obvious problems with 
>>> using OAI-PMH for synching RDF are listed.
>>> Thanks,
>>> Shlomo
>>> Experience the all-new, singing and dancing interactivePrimo 
>>> brochure <http://www.exlibrispublications.com/primo/>
>>> *From:*Bibliographic Framework Transition Initiative Forum 
>>> [mailto:[log in to unmask] <http://LISTSERV.LOC.GOV/>]*On 
>>> Behalf Of*Murray, Ronald
>>> *Sent:*Thursday, August 29, 2013 22:13
>>> *To:*[log in to unmask] <mailto:[log in to unmask]>
>>> *Subject:*Re: [BIBFRAME] What used to be uniform titles
>>> One could cache the relevant information locally, and sync at a 
>>> prudent interval - but default to using the online sources. Its 
>>> rather the opposite of what a UPS does, but one is covered against 
>>> network-related data problems.
>>> Ron Murray
>>> *From:*Bibliographic Framework Transition Initiative Forum 
>>> [mailto:[log in to unmask] <http://LISTSERV.LOC.GOV/>]*On 
>>> Behalf Of*Mitchell, Michael
>>> *Sent:*Thursday, August 29, 2013 2:45 PM
>>> *To:*[log in to unmask] <mailto:[log in to unmask]>
>>> *Subject:*Re: [BIBFRAME] What used to be uniform titles
>>> I know many people are enamored with keyword searches but I'd hate 
>>> to lose the availability of browse searches of authorities for our 
>>> users in pursuit of unknown and unnamed goals. I don't think we can 
>>> build the necessary local indexes without local storage of 
>>> authorities. Including both text and IDs makes sense when the IDs do 
>>> have a purpose.
>>> Mike M.
>>> *From:*Bibliographic Framework Transition Initiative Forum 
>>> [mailto:[log in to unmask]]*On Behalf Of*Stephen Hearn
>>> *Sent:*Thursday, August 29, 2013 1:07 PM
>>> *To:*[log in to unmask] <mailto:[log in to unmask]>
>>> *Subject:*Re: [BIBFRAME] What used to be uniform titles
>>> Current systems, maybe not. But we're trying to move toward an 
>>> environment wherein the local system can take in a record stocked 
>>> with machine-actionable IDs and reliably retrieve from the 
>>> identified sources whatever kind of text representation is preferred 
>>> based on automated negotiation with linked data sources.  The 
>>> retrieved texts would then be used to build local indexes and 
>>> displays. Until that becomes standard practice and maybe well beyond 
>>> that point, bib data will continue to include text strings for 
>>> subjects, authors, etc.; meanwhile we'd like the IDs to be there, 
>>> too, so new kinds of processing and data management can be supported.
>>> Stephen
>>>
>>> On Thu, Aug 29, 2013 at 9:41 AM, Mitchell, Michael 
>>> <[log in to unmask] 
>>> <mailto:[log in to unmask]>> wrote:
>>> A naive question here. For all these entitiesrepresented primarily 
>>> by a machine-actionable ID, do we expect they be able to be used by 
>>> our LIS systems to form left-anchored browse lists related to our 
>>> local resources? Subjects, authors, "uniform" titles? I'm not seeing 
>>> local system authorities indexing if we are using IDs/URI's that 
>>> pull remote text on demand. I'm probably missing something here.
>>> Michael Mitchell
>>> Technical Services Librarian
>>> Brazosport College
>>> Lake Jackson, TX
>>> Michael.mitchell atbrazosport.edu <http://brazosport.edu/>
>>> *From:*Bibliographic Framework Transition Initiative Forum 
>>> [mailto:[log in to unmask] 
>>> <mailto:[log in to unmask]>]*On Behalf Of*Stephen Hearn
>>> *Sent:*Thursday, August 29, 2013 9:10 AM
>>>
>>> *To:*[log in to unmask] <mailto:[log in to unmask]>
>>> *Subject:*Re: [BIBFRAME] What used to be uniform titles
>>> I doubt that we'll ever abandon the idea of uniformly constructed 
>>> text strings to represent instances of things in categories. What 
>>> were moving toward instead is a shared system where the identity of 
>>> things such as Beethoven's 9th symphony is represented primarily by 
>>> a machine-actionable ID. That ID in turn will be associated with one 
>>> or more standard  text strings for representing the Work in 
>>> appropriate contexts.  Full heading strings will still be 
>>> appropriate in index lists. Clusters of faceted information 
>>> associated with the ID will be another version of this 
>>> representation, useful for faceted result displays. Associating a 
>>> collection with the IDs for the Works it contains will be  more 
>>> important than associating it with particular text strings; but the 
>>> end user views will still follow some kind of cataloging standard 
>>> for textual representation.
>>> Stephen
>>> --
>>> Stephen Hearn, Metadata Strategist
>>> Technical Services, University Libraries
>>> University of Minnesota
>>> 160 Wilson Library
>>> 309 19th Avenue South
>>> Minneapolis, MN 55455
>>> Ph:612-625-2328 <tel:612-625-2328>
>>> Fx: 612-625-3428 <tel:612-625-3428>
>>>
>>>
>>> --
>>> Stephen Hearn, Metadata Strategist
>>> Technical Services, University Libraries
>>> University of Minnesota
>>> 160 Wilson Library
>>> 309 19th Avenue South
>>> Minneapolis, MN 55455
>>> Ph: 612-625-2328
>>> Fx: 612-625-3428
>>
>
> Rurik Thomas Greenall
> NTNU University Library | NTNU Universitetsbiblioteket
> [log in to unmask] <mailto:[log in to unmask]>
> @brinxmat
> http://folk.ntnu.no/greenall
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager