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