On Fri, 15 Mar 2013, Vesa Sivunen wrote:
> We have situations where the record could go to several (virtual)
> collections. Will Invenio get hick ups if the field 980 is repeated?
> For example:
>
> ...
> 980__$$aCOLLECTION_A
> 980__$$aCOLLECTION_B
> 980__$$aCOLLECTION_C
This will be perfectly OK. What we've been usually doing is to have
only one 980__a tag containing primary collection, and any number of
repetitive 980__b tags containing all secondary collections the record
may belong to. If primary/secondary collection distinction is
important, then you can do the same. If collections are equal citizens,
so to speak, then it is good to simply multiply 980__a. Let the
decision be driven by the data model logic, and the software
accommodates. :)
> What happens if the record is deleted?
Usually 980__c with value DELETED is added to the record. When it is
there, then the concerned record will be hidden from public eyes,
whatever other 980__a values it may have.
Another hard-delete technique is not to have any 980. If such a record
does not match the definition of any collection, then it won't be
displayed to public eyes either.
> And related to that, should 980__c subfield be normally empty?
Usually there should be no 980__c.
* * *
BTW, another useful thing to know WRT deletions may be 970__d tag which
basically means record-ID-of-the-record-this-dupe-was-merged-with. It
is used when one finds a duplicate record, deletes the dupe copy, and
one wants to keep the reference from the deleted copy to the surviving
record. So that if an admin deleted record 123 in profit of record 456,
and a user bookmarked /record/123 in the past, then this would be
automatically resolved onto /record/456 via 970__d kept in record 123.
(Ditto for user basket contents etc.)
Best regards
--
Tibor Simko
