V-sources, of course there is a Dutch library using an ERM solution

Joost de Vletter from Eindhoven University addressed me to say they have developed V-sources an ERM system, which they use and is going to be used by Delft University as well. Two posts ago I said I did not know of any Dutch libraries using an ERM system.
I was thinking of the efforts of the consortium of Dutch University libraries and the Royal Library to select a system. These efforts were unsuccessful so far. I forgot that Eindhoven invested in developing a system themselves, which will also be available commercially.

Joost also reacted on my remarks about the lack of integration of management of paper and electronic subscriptions. He answered that their system, like most other ERM systems is based on the DLF (Digital Library Federation) ERMI document. This describes a data model that does not consider the administration of paper subscriptions. He is right and following standards is a very good thing. And since these new library system components are far more open then before, it is probably easier to link between the paper subscription in one system and the electronic subscription in the other. However, the 'old' serials management systems of most vendors will not be that open, which will probably make integration more difficult. I sometimes think that vendors use the component based architecture argument to just sell more sytems.

Don't get me wrong, I am all for component based and even service oriented architectures, but not for just a part of our systems. Our management problems with electronic subscriptions, with mostly 'big deals' do not justify a separate ERM system. We can solve our problems with extra features within the serials management system. However, if there would be a national ERM system, shared between university libraries we would also benefit from a single point of administration. That would be a reason to implement ERM, assuming it would have a rich set of web services available. I heared from Thomas Place of Tilburg University, he is thinking in this same direction and I think most Dutch university libraries will consider this a good way to go.

European Library Automation Group - 32nd ELAG Library Systems Seminar - 14-16 april 2008

We have just opened the web site we have created (using WebQuery of course)for this years ELAG conference, which we will host in April. I will present a paper on our "Digital Library" as we call our library website. I will speak about our decisions and efforts to start building a Library Content Management System. There will be a lot of other interesting papers as well. Another exciting thing about ELAG meetings are the workshops. ELAG is not about listening to presentations only. You participate in one workshop during the conference and discuss a subject. Workshop reports are presented on the last day. This year you can also come and talk, without having to prepare a paper!!! You can express your ideas in 5 minute ligthning talks. So join us. Be fast. Convenient hotel accomodation nearby is limited.

Serials Management, the last conversion

This week we hope to start using our new serials management application. The last application that is still running on our old system. Cardex, the name of the application, is now based on the new CMS. It is entirely build using XSLT, some javascript and a bit of perl that does background printing and emailing of claims for missing issues or stagnating subscriptions. The old version, which has been used until now was build in 1982 (to be honest, the first patch of the code dates back to november 1982, so I presume 1982 must have been the year it was born). It was based on Minisis and written in SPL, a Pascal like proprietary programming language for the HP3000 series computers. Although the application was old, it had evolved over the years and people were pretty happy with it. We kept the same application properties, but the application, a web application now, has got a completely different look and feel. It now has all the old features and some more. Next step is to put in new functionality concerning electronic subscriptions or to integrate it with components for this, so called Electronic Resource Management (ERM) systems. The problem is, that I have not seen systems that make the connection with traditional serials management systems, which is quite strange, especially since subscriptions are often paper plus digital content (ok, it is changing). They do integrate with Open URL resolvers and sometimes with cataloging components. It feels like these systems force to separate paper and electronic serials management, just like in most systems, cataloging digital content (in meta search portals and OpenURL systems) is separated from traditional cataloguing of paper content in a ILS. Vendors have not split up their traditional ILS's into components yet.
For now I think we have to built these features ourselves. So far, no Dutch library I know has implemented a ERM system. Am I wrong ?

By the way ......

One of my last posts in Dutch I mentioned we were running WebQuery version 5.34. Now, two years later we are running version 5.52 This latest version introduced PAM (plugable authentication module) authentication. This is our first step towards implementing federated authentication.

Code reviewing

We are working with 8 people on the sytem now. Six of them do application development and we have reached a point where we have to consider implementing some quality control tools. One of them is code reviewing. We started with this recently. We have found it too much to start doing it systematically, for the moment. So we do not have every bit of code reviewed. We will take a piece of code every month and one of us, not the developer, will write e review and present this to the rest of us. We spend a morning discussing the review. This will lead to agreements on coding standards and one of us will document this in our wiki.
So far we have had only one review. The discussions at the moment are very much about very basic standards we have never explicitly formulated. I suppose that later on we will discuss more local practices. I think we have found an excellent way to create acceptable standards. Everybody is excited about it.

And now I will continue ...

I have been very quiet on this blog for two years !!
We have been working hard on implementing all library applications using the LCMS and I haven't found the urge to report about it. However, blogging has become more popular over the last two years and reading blogs as well. I will also start blogging in English (please be merciful !) since this might appeal to a much larger community.

En waneer je nu eens geen text retrieval wil doen ?

Ik heb vorige week de Gewasbeschermingskennisbank overgebracht naar Oracle. Het probleem dat daarbij boven water kwam, is dat we in oracle niet zo eenvoudig text indexen en volledig veld indexen door elkaar kunnen gaan gebruiken. Op dit moment ondersteunen we per tabel in wqoracle 4 indexen. Op recordnummer, op datum van invoer, op datum van wijziging en de context-index voor text retrieval op de inhoud van de XML elementen.
Bij de gewasbeschermingskennisbank moet echter het onderscheid kunnen worden gemaakt tussen middelen die zijn toegestaan in "siergewassen onder glas" en middelen toegestaan in "plantgoed voor siergewassen onder glas". Deze laatsten worden ook gevonden als je zoekt naar "siergewassen onder glas".
De wat onbeholpen work-around die ik er nu voor gebruik is om naast het normale xml element een tweede xml element te definiëren met dezelfde inhoud maar ontdaan van woordscheidingstekens, zoals spaties en die te gebruiken voor de zoekactie.
Het werkt, maar ik denk dat we de mogelijkheid moeten inbouwen om 'normale indexen' te kunnen gebruiken (normaal in de database wereld, anders dan die wij in onze bibliotheekomgeving doorgaans gebruiken) en ergens in een zoekcommando moeten kunnen geven dat we voor een bepaald veld de andere dan de contextindex moeten gebruiken

WebQuery 5.34

Inderdaad, alweer een nieuwe versie van WebQuery.

Deze versie is vandaag in gebruik genomen vanwege de correctie van een fout in de afhandeling van de multipart-variant van de formulierafhandeling. Deze fout trad alleen op in formulieren waarmee een bestand werd overgebracht naar de server. Onder bepaalde omstandigheden werd dan een deel van het formulier na de browse-knop niet of niet goed verwerkt. Dat probleem is in deze versie opgelost.

Er is één andere wijziging: wq_sfx wordt nu standaard meegegeven als xslt-parameter ($wq_sfx). Doel hiervan is om uniformering van de "next"
link en evt. andere links te vereenvoudigen. De xslt "ora-default.xslt", bedoeld als vervanging en uitbreiding van ora_errors.xslt, maakt hier al gebruik van (let op het streepje: dat is een minteken, geen underscore).
De nieuwe uitleen gebruikt deze xslt in de testomgeving.

WebQuery 5.33 en wqoracle 1.3 actief

Zoals je aan het onderwerp al zag, er zijn weer nieuwe versies van WebQuery en wqoracle in gebruik genomen, en daarbij hoort een lijstje met de wijzigingen ten opzichte van de vorige versie:

WebQuery 5.33 (in combinatie met wqoracle; ik test nieuwe features als deze niet meer met wqstub/mindbsrv, dus gebruik het daarmee niet): wq_max, waarmee in een zoekvraag het te tonen aantal records per resultaatpagina kan worden opgegeven, kent en nieuw gebruik. Als aan wq_max de waarde 0 wordt meegegeven, wordt alleen het aantal hits getoond en geen resultaat set. In de oude versie had wq_max=0 het zelfde effect als het weglaten van wq_max (dan wordt de default-waarde van hit-limit uit de cgiparm parameter file gebruikt). Hiermee vervalt tevens het keyword "hits" (achter de servicenaam in de url), dat vrijwel nooit gebruikt is en in combinatie met wqoracle niet werkte.
Verder worden nu om alle zoektermen (behalve in wq_qry) haakjes gezet, om te voorkomen dat onbedoeld op alle velden gezocht wordt.

Ik wil er nogmaals op wijzen dat oracle context indexen (en dus ook het zoekmechanisme in wqoracle) een groot aantal niet-alfanumerieke tekens als operators interpreteert. Een paar voorbeelden (de aanhalingstekens zijn een markering van de zoekterm, tik die dus niet in als je het effect wil zien): zoek je op "plant-hg", dan vind je alle records, waarin het betreffende veld de kreet "plant" staat, NIET gevolgd door "hg". Zet accolades om de zoekterm, of een backslash voor het minteken, als je dat wilt voorkomen. "{plant-hg}" en "plant\-hg" geven het gewenste resultaat. "A&F" vindt alle records waarin in het betreffende veld zowel een A als een F staan (vergelijkbaar met het zoeken op "A F" in minisis). Ook hier helpen accolades en backslash om de kreet "A&F" te vinden. "A F" heeft in dit geval het zelfde effect, omdat je dan zoekt naar een losse "A" gevolgd door een losse "F", en de index de "&" in het record afwijkend behandelt. Vermijd ook woorden als "AND" en "OR" in een zoekterm, tenzij je die bewust als operator gebruiken wilt. Gebruik haakjes en accolades altijd in paren, en realiseer je dat "plant soil" (39 hits in titel) niet meer het zelfde resultaat geeft als "soil plant" (124 hits) of "soil & plant" (1536 hits). Kortom, "elluk foordeel hep se nadeel".

wqoracle 1.3: wq_max=0 (zie hierboven). Daarnaast is een interne wijziging doorgevoerd op verzoek van oracle, als workaround voor een van de oracle-bugs die tot problemen bij het zoeken leidde. Deze wijziging komt er op neer dat de xml-velden nu in porties van 4000 bytes worden opgehaald uit de database, in plaats van zoveel mogelijk in één keer. Tenslotte is de maximale veldlengte van 132KB naar 1MB uitgebreid omdat isn 51066 in titelplus te groot was (ca 250KB).

Age Jan

Uploaden van documenten in een database

Al enige tijd bestaat de mogelijkheid om bestanden toe te voegen aan records in een database. Op dit moment gebeurt dat bij Wageningen UR publicaties, maar we gaan dat nu bijvoorbeeld ook doen bij de documentatiedatabase van COGEM (COmmissie GEnetische Modificatie)en bij de leermiddelendatabase in het kader van LORENET. Deze laatste 2 databases zijn echter Oracle databases en dat heeft wat consequenties. Oorspronkelijk draaide de Minisis db server en WebQuery allebei op de HP3000. Het uploaden van een bestand was een gecoordineerde actie tussen die twee processen, op dezelfde computer op basis van afspraken over de plaats van die bestanden. Tegenwoordig draait WebQuery op de Web server en WQoracle op de database server. WebQuery slaat de bestanden niet op in de database, maar gewoon in directories op de web server. De bestandsnaam wordt vervolgens doorgegeven aan WQoracle waarna het in de database wordt opgeslagen. Bij invoer van een record is er een bestandsnaam gegenereerd die weliswaar de naam van de tabel bevat, maar verder betekenisloos is. Wordt het bestand toegevoegd aan een bestaand record, dan wordt het ISN meegenomen in de bestandsnaam. Zo is een bestand altijd terug te herleiden tot een uniek database record. Wanneer er nog geen record is, kan dat natuurlijk niet. Wanneer de interface het enigszins toestaat, probeer dan in het invoerscherm het uploaden niet aan te bieden, maar doe dat pas nadat het record is ingevoerd.
Het verwijderen van een file is een ander probleem. WebQuery en WQoracle zijn gescheiden processen, niet gekoppeld door een transactie logging mechanisme. Wanneer je een nieuwe file toevoegt in plaats van de vorige, of je wil er een verwijderen, dan kun je het record aanpassen en eventueel een nieuwe file uploaden, maar er is geen mechanisme om een oude te verwijderen. Deze blijven dan 'los' in de directory achter en dat geeft vervuiling. WQoracle zou WebQuery kunnen 'informeren' over een te verwijderen file, maar als het verwijderen mislukt dan hebben we geen mechanisme om de hele boel terug te draaien. Vervuiling blijft dan dus mogelijk.
We zouden er ook voor kunnen zorgen dat de filename nooit uit het XML kan worden verwijderd, maar dat alleen een delete attribuut kan worden aangezet, waar je dan in het stylesheet rekening moet houden (dit maakt ook een UNDELETE mogelijk) We zouden dan periodiek in batch kunnen opschonen. We denken erover na. Heb je een brilant idee, laat horen !!

WebQuery op het web

Bij wat zoekacties naar deze blog op Google kwam ik twee leuke dingen tegen. Allereerst een WebQuery handleiding van mijn hand in het Spaans. Nou ja, wel een oude handleiding en een soort van samenvatting. Grappig dat iemand dat heeft gedaan, Met name omdat we alleen een Nederlandse, Engelse en Franse versie hebben gemaakt. Er is nooit Spaanse interesse voor WebQuery geweest. Er is overigens ook een geregistreerd product met dezelfde naam. Iets om op te letten.
Een tweede ding is een alternatieve manier om vanuit huis 'off campus access' tot de desktop library te krijgen. Zoek in Google op 'pauzeren' en klik op het derde resultaat. Klik op de login knop en vervolg ...... niet iets om in de helpteksten op te nemen :)

characters sets en foutafhandeling

wellicht ten overvloede nog even een paar opmerkingen over xslt's in samenwerking met WebQuery:

a) als er gebruik gemaakt wordt van xslt's (dus inmiddels bijna altijd) bepaalt WebQuery aan de hand van de output opties van de xslt wat de eigenschappen van de output zijn. Neem dus in IEDERE xslt een output regel op, en geef daarin een method en een encoding aan. Vergeet je die, dan zijn de defaults xml en utf-8, dus waarschijnlijk niet wat je wilt.

b) als er een fout optreedt buiten de xslt, wordt ALTIJD de xslt aangeroepen. Bij een aantal algemene fouten kan dat een andere dan de "gewenste" xslt zijn, omdat wq_sfx dan nog niet is geinterpreteerd. Zorg er dus voor dat IEDERE xslt gebruik maakt van (voorlopig nog) ora-errors.xslt voor de foutafhandeling.

Klaar voor OAI interface !

In minisis konden we zoeken op een range van waarden, bijvoorbeeld jaren van uitgave, door de twee waarden gescheiden door een dubbele slash als zoek criterium mee te geven. (bv 1950//1960 of sneeuw//sneeuwschuiver). Dit is niet erg eenvoudig te realiseren in een text georiënteerde zoekindex. In Minisis is het pas in een van de laatste versies op veler verzoek geïmplementeerd. In Oracle text retrieval bestaat deze mogelijkheid dus niet.
Dit is een probleem voor onze OAI (Open Archive Inititative) interface op de Wageningen UR publicaties.
Daarvoor moeten we namelijk eenvoudig kunnen zoeken naar gewijzigde dan wel ingevoerde records tussen twee datums. Om dit mogelijk te maken moeten we een extra index definiëren. We hadden tot nu toe voor iedere Oracle tabel 2 indexen. De text index op het gehele xml document en een aparte index voor het ISN. Er komen nu standaard 2 indexen bij voor de invoer- en wijzigingsdatum van een record.

In WebQuery 5.32 en wqoracle 1.2, die sinds gisteren de productieversies zijn, is het gebruik van deze nieuwe indexen mogelijk gemaakt. Je kunt nu in de "creation date" en de "modification date" zoeken op een range . Daarvoor zijn twee nieuwe pseudo-velden gedefinieerd, wq_cdt en wq_mdt. De zoekstring voor deze velden MOET een (één) slash bevatten als delimiter tussen begin- en eind-moment. Beide momenten mogen afgekapt worden waar je wilt. Een paar voorbeelden: wq_mdt=2005-10/2005-11 zoekt alle in oktober gewijzigde records in dit geval in de NIEUWS database.
De zoekvraag wq_cdt=2005-10-19T11:30/2005-10-20 betekent: zoek alle op 19 oktober na 11:30 uur ingevoerde records.

Zo kan ook de OIA interface op Wageningen UR publicaties gebruik gaan maken van de snellere Oracle database.

De nabijheidsoperator

In een eerdere post vertelde ik al dat in het nieuwe Bibliotheek Content Management System we te maken hebben met standaard 'phrase searching' en dat word searching expliciet moet worden gedaan door het gebruik van de 'AND' operator. We hebben nu echter ook de "near()" operator om te zoeken naar woorden binnen een record. Zo kan bijvoorbeeld met http://library.wur.nl/WebQuery/wurpubs?title=near((water,management),2) gezocht worden naar alle records in WaY waarbij in de titel de woorden water en management voorkomen, mits tussen deze woorden maximaal 2 andere woorden zitten.
In dit geval vinden we dus titels waarin "water management" staat, maar ook "water quality management" en "management of irrigation water" wordt gevonden.

Waarom zie je nieuwe records soms niet op het web ?

Wanneer je, op dit moment, een nieuw record of nieuw exemlaar in de catalogus invoert, dan valt op dat je het record of exemplaar nog niet in de catalogus op het web kunt vinden. Dit verschijnsel is een gevolg van de wijze waarop Minisis het laatst ingevoerde record bijhoudt. Om deze 'pointer' bij te werken moet Minisis namelijk de database heropenen. Op het web wordt de database in principe alleen 's-avonds gesloten en heropent en soms overdag als een zoekvraag een time out veroorzaakt. Vandaar dat je de nieuwe dingen doorgaans pas de volgende dag ziet verschijnen in de webcatalogus. In de Oracle situatie is dat straks afgelopen en zal je de nieuwe records wel direct te zien krijgen.

SEP overzichten snel te genereren in WebQuery Oracle

SEP (Standard Evaluation Protocol) overzichten zijn verplicht materiaal voor de wetenschappelijke verslaglegging. Die zijn nu eenvoudig te genereren uit WaY met één stylesheet. Het duurt weliswaar een seconde of 4 á 5 maar dan staat ie er. Daarvoor zijn in die tijd 72 (!!) zoekvragen aan WebQuery gesteld. Dan is die response tijd wel acceptabel dacht ik.

zoeken op PLANT-BZ geeft als resultaat PLANT-HG

Da's raar. Zoeken op PLANT-BZ geeft PLANT-HG :) Dat is nou het gevolg van het transparant doorgeven van zoekvragen aan Oracle text Retrieval. Wanneer in de text een Oracle operator staat wordt dat doorgegeven. Dat kunnen we voorkomen, maar dan kunnen subtiele dingen als het afwijken van standaard 'phrase searching' (zie mijn vorige post) niet meer. Dus het is uitkijken met die operatoren. De '-' is bijvoorbeeld zo'n operator. Zoeken op het acroniem PLANT-BZ is dus zoeken op records waar in het acroniem het woord PLANT staat, mits er niet het woord BZ in voorkomt !!! Wil je voorkomen dat operatoren niet als zodanig worden herkend dan moet je om het geheel accolades zetten. Wil je dat sommige operatoren wel ( in dit geval 'or' om zowel PLANT-BZ als PLANT-HG te vinden) worden herkend en anderen niet, escape dan die niet gewenste operatoren met een '/'.

Word searching en phrase searching

Ofschoon we met WebQuery eigenlijk verschoond willen blijven van database afhankelijke dingen, blijkt het in de praktijk toch te verleidelijk om niet gebruik te maken van directe kracht van onderliggende database. We gaan er maar van uit dat we niet te vaak van database zullen wisselen. Daarom toch maar wat oplossingen gebaseerd op Oracle text retrieval.
Onder Minisis was zoeken in een veld standaard 'word searching'. Onder Oracle is het standaard 'phrase searching'. Om toch word searching te doen binnen een veld moet je expliciet een operator tussen woorden gebruiken. In Oracle text retrieval is dat bijvoorbeeld 'and' en | of 'or'. In plaats van een 'or' of | mag je ook een comma gebruiken. Het heeft een iets andere betekenis, maar in de praktijk geeft het hetzelfde resutaat als een or. Vergeet niet haakjes om de totale vraag te zetten. We gaan dat overigens WebQuery automatisch laten doen.

Waarom niet in het Nederlands

Ik ben deze blog begonnen in het Engels. Ik denk echter dat het interessanter is om hem voornamelijk intern te gebruiken binnen Bibliotheek Wageningen UR. Misschien zelfs voornamelijk binnen AOB. Vandaar dat ik maar over ga in het Nederlands. Op dit moment ben ik zelf bezig met Cardex en Way.

wijziging en invoerdatum en wijziger / invoerdersnaam in records

Ik heb gisteravond een nieuwe versie van item, lener en rubriekgedownload. Daarin zitten nu de invoerdatum, invoerder, wijziginsdatumen wijziger in de record attributen cd, cu, md resp mu. Die worden doorwqoracle automatisch bijgewerkt. Daarnaast is in item de veldnaambibliotheek-laatste-status aangepast (er stond laaste ipv laatste).
Ik probeer vandaag de attributen van titelbeschrijving op de (hopelijk)juiste plek te zetten; als dat lukt staat die morgen vernieuwd op deserver. Voor alle vier geldt dat de gegevens dan up-to-date zijn toteergisteren (door een diskruimteprobleem op de hp3000 zijn de bestandenhelaas niet 100% synchroon, er zijn ook wat gegevens van gisterengedeeltelijk verwerkt. Voor het testen zal dat waarschijnlijk geenprobleem zijn).
Nog even een opmerking over invoerdatum en invoerder. Het is debedoeling dat die attributen er op recordniveau ALTIJD zijn, en wqoraclemaakt ze ook altijd aan bij nieuwe records. Bij conversies m.b.v hetconversiescript worden ze daarom vanaf gisteren ook altijd aangemaakt.De algoritme daarvan zit als volgt in elkaar:
- Als er een veld is dat naar éém van die attributen moet wordengeconverteerd, is het noodzakelijk om een conversie-xslt analoog aan devolgende te maken (dit is de huidige versie lener-conversie-utf8.xslt,waarin alle velden nog met hun minisis-tag worden opgenomen):
<?xml version="1.0" encoding="utf-8"?><xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"xmlns:exsl="http://exslt.org/common" extension-element-prefixes="exsl"version="1.0"> <!-- AJK 2005-10-19 --> <xsl:import href="default-conversie-utf8.xslt"/> <!-- --> <xsl:output method="xml" version="1.0" encoding="utf-8"indent="yes"/> <!-- LENER --> <xsl:template match="lenerLENER" mode="conversie"> <xsl:element name="lener"> <xsl:apply-templates select="@*" mode="copy"/> <xsl:apply-templates select="N100/N101"mode="cu-attribute"/> <xsl:apply-templates select="N100/N102"mode="cd-attribute"/> <xsl:apply-templates select="N100/N103"mode="mu-attribute"/> <xsl:apply-templates select="N100/N104"mode="md-attribute"/> <xsl:apply-templates select="*" mode="copy"/> </xsl:element> </xsl:template> <!-- do NOT copy the following elements --> <xsl:template match="N101N102N103N104" mode="copy"/> <!-- --></xsl:stylesheet>
de modes "cu-attribute", "cd-attribute", "md-attribute" en"mu-attribute" regelen dat de inhoud van de genoemde velden wordenomgezet in de aangegeven attributes. Voor datumvelden gaan de templateser van uit dat de datum er als "jjjj-mm-dd" in staat. Daar wordt dan"T00:00:00Z" aan toegevoegd om er een geldige timestamp van te maken.
Als er aan het record-element NIET op bovenstaande wijze een cd- en eencu- attrubute zijn toegevoegd, wordt in het cu-attribute "conversie"gezet. Voor het cd-attribute is het iets ingewikkelder. Als er wel eenmd-attribute is gemaakt, wordt dat in het cd-attribute gekopieerd. Alser ook geen md-attribute is, wordt er het tijdstip in gezet waarop dexml-conversie gestart is.
Tenslotte, nu ik het toch over de attributen heb, nog even een uitlegvan de manier waarop wqoracle die dingen vult.Als een record wordt ingevoerd, worden cd en cu op recordniveau gevuldmet de het huidige tijdstip en de gebruikersnaam van degene die inWebQuery is ingelogd. Als niet is ingelogd wordt het ip adres alsgebruikersnaam gebruikt, maar in principe is inloggen verplicht voorvrijwel elke update-functionaliteit.Als een record wordt gewijzigd worden md en mu op analoge wijze gevuldresp aangepast. Bovendien wordt rv met één verhoogd.
Iets soortgelijks gebeurt met de eventueel op andere niveaus van de xsdgedefinieerde attributen. Daarbij gelden echter twee beperkingen omervoor te zorgen dat alleen zinvolle gegevens worden vastgelegd:
a) invoerattributen (cd en cu) worden gevuld op het hoogst mogelijkeniveau. Bij een nieuw record dus allleen op recordniveau.
b) wijzigingsattributen (md, mu en rv) worden gevuld op recordniveau énop het laagst mogelijk niveau.
c) als op een bepaald niveau de attributen niet gedefinieerd zijn komenze terecht op het eerstvolgende hogere niveau waar ze wel gedefinieerd zijn, Age Jan Kuperus