LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


[email protected]


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:

"Wallis,Richard" <[log in to unmask]>

Reply-To:

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

Date:

Mon, 2 Sep 2013 11:40:57 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (127 lines)

Jörg

On 2 Sep 2013, at 09:48, Jörg Prante <[log in to unmask]> wrote:

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

I agree that as RDF, and from its ambitions, Bibframe implementations should embrace the principles you mention - meaning that models and vocabulary should be serialisation independent and identifiers should be dereferenceable and cool.  However many will still want to move data around in chunks, encoded in some RDF serialisation but not using web protocols e.g. ftp.  I am basically agreeing with you, whilst warning others not to get hung up on protocols whilst designing the model & vocabulary to describe their resources.

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

Couple of points here.  id.loc.gov almost certainly will not, and should not, become the authority hub for the whole bibliographic web.  Authorities should be referenced from all sorts of sources across the web some may be global and general such as id.loc.gov & viaf.org, others may be more focused and specific such as an individual university or interest group.

Secondly, many assume that every time a URI is used its hosted server gets a request.  Often a URI is only used in the capacity of the third letter of its acronym - an identifier - not requiring network traffic any more than using an isbn does.

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

Quite right - keep the model and vocabulary protocol & serialisation independent - that way the most appropriate technical solution can be applied for any situation, whatever it it.

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

+1

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

What a good idea.  A parallel implementation(s) guide would help draw some of the technology specific debate away from confusing the modelling and vocabulary discussion.  Not that implementation is not important, just separate.

~Richard.

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

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
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