LISTSERV mailing list manager LISTSERV 16.0

Help for ID Archives


ID Archives

ID 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

ID Home

ID Home

ID  April 2012

ID April 2012

Subject:

AW: [ID.LOC.GOV] Atom feeds and deleted records

From:

Neubert Joachim <[log in to unmask]>

Reply-To:

Authorities and Vocabularies Service Discussion List <[log in to unmask]>

Date:

Mon, 23 Apr 2012 15:11:35 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (122 lines)

Dear Kevin,

Thanks for the hint - another nut to crack. I have to check how it works in our thesaurus management system. For the collegues at the DNB, this could be an issue, too, when they start publishing modification times in RDF.

The cleanest way, in my eyes, would be to update the modification time for the target record if the relation in the source record is added or deleted - but this could turn out as virtually impossible with our legacy systems.

Cheers, Joachim

> -----Ursprüngliche Nachricht-----
> Von: Authorities and Vocabularies Service Discussion List 
> [mailto:[log in to unmask]] Im Auftrag von Ford, Kevin
> Gesendet: Freitag, 20. April 2012 23:09
> An: [log in to unmask]
> Betreff: Re: [ID.LOC.GOV] Atom feeds and deleted records
> 
> Dear Joachim,
> 
> I had a thought about this:
> 
> > Any hints, if we try to set up something similar?
> 
> The ATOM feed from ID is based on the modification times in 
> the source MARC records.  When there is a change to the 
> underlying MARC record, the modification date/timestamp will 
> be updated accordingly.  Also, the source MARC records only 
> contain broader relationships.  So, if a broader relationship 
> is deleted (or added) then the modification time of that 
> particular record would be updated accordingly.  Easy enough.
> 
> But, unlike the MARC records, ID expresses relationships 
> bi-directionally.  In addition to broader relationships, ID 
> expresses narrower relationships.  A change involving a 
> broader relationship in a MARC record might impact a 
> published narrower relationship at ID.  The Concept that 
> expressed a deleted or new narrower relationship, therefore, 
> would not be represented in the ATOM feed.
> 
> A quick illustration of this might be helpful, using the 
> entry for "Persons" as an example:
> 
> http://id.loc.gov/authorities/subjects/sh85100163
> 
> "Persons" expresses no broader relationships.  You'll note, 
> however, "Persons" has many narrower relations, such as 
> (chosen at random): "Prostitutes," "Prostitutes' customers," 
> "Employees," "Shooters of firearms," "Slackers," and so on 
> (interestingly, "Gifted persons" and "Intellectuals" are 
> narrower concepts of "Persons" but not something like 
> "Idiots" - but I digress).  This is, of course, because the 
> narrower relationships are determined based on the expressed 
> broader relationship found in the Concepts related to 
> "Persons."  All of those narrower concepts you see when 
> viewing the entry for "Persons" have an expressed broader 
> relationship to "Persons" in the original MARC record.  
> 
> So...should any one of those narrower Concepts (such as 
> "Slackers") stop asserting a broader relationship to 
> "Persons," then it would affect the resource for "Persons" at 
> ID since a narrower relationship to "Slackers" would no 
> longer be asserted.  But, because the underlying MARC record 
> for "Persons" was not modified, you will not see a change for 
> "Persons" appear in the ATOM feed, even though it now has one 
> fewer narrower relation.  You would only see a change notice 
> for "Slackers."  Such is the pitfall of expressing 
> relationships bi-directionally when the source data does not 
> also express relationships bi-directionally.
> 
> I don't know where this leaves you other than to say that 
> when you are altering expressed relationships of one Concept 
> that you should bear in mind how that change might alter the 
> relations in other Concepts you did not explicitly touch, and 
> that you might want to be sure to update the modification 
> time of the related Concept (even if you made no direct 
> change to it).  Alternatively, tell users of the ATOM feed to 
> rely on specific, one-way relationships from which users can 
> derive the inverse relationship (or offer an ATOM-feed 
> specific version of the data that only includes one-way 
> relationships).  In that way, for example, users of ID data 
> would only ever store broader relations, from which it is 
> possible to derive the narrower relations.
> 
> HTH,
> 
> Kevin
> 
> --
> Kevin Ford
> Network Development and MARC Standards Office Library of 
> Congress Washington, DC
> 
> 
> 
> 
> 
> > From: Neubert Joachim [mailto:[log in to unmask]]
> > Sent: Friday, April 20, 2012 1:51 PM
> > To: Ford, Kevin
> > Cc: [log in to unmask]
> > Subject: Atom feeds and deleted records
> > 
> > Hi Kevin,
> > 
> > At a meeting in Germany, we recently discussed how to trace and 
> > communicate changes in large authority files. I remembered 
> that LoC is 
> > providing atom feeds for this. As I understand it, the 
> feeds only give 
> > the information that something re. an URI has changed. The 
> consuming 
> > party has to look up the URI to figure out if it is new (by the 
> > according dates), or what particularly has changed (by 
> comparison with 
> > a prior version). However, how is the deletion of a resource 
> > communicated?
> > 
> > Do you (or somebody else on the list) have information how this is 
> > used, and how it works in practice? Any hints, if we try to set up 
> > something similar?
> > 
> > Cheers, Joachim
> 

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 2024
January 2024
March 2023
January 2023
July 2022
June 2022
May 2022
April 2022
February 2022
November 2021
September 2021
August 2021
July 2021
June 2021
May 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
March 2020
February 2020
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
April 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2017
July 2016
February 2016
January 2016
December 2015
November 2015
September 2015
August 2015
June 2015
March 2015
February 2015
October 2014
August 2014
July 2014
June 2014
March 2014
January 2014
November 2013
September 2013
August 2013
June 2013
May 2013
April 2013
March 2013
December 2012
November 2012
October 2012
September 2012
August 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
April 2011
March 2011
February 2011
January 2011
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
November 2009
June 2009
May 2009

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager