Formalizzazione della revisione dei requisiti
Fase 1
Ciò che il sistema dovrà fare sarà:
- Prendi N record dalle tabelle dcmi e optionalfield
- La scelta degli N record verrà presa in base alla dataElaborazione più vecchia (da decidere se prendere la dataElaborazione della tabella dcmi/optionfield o se quella della tabella RootObject)
- Per ogni record precedentemente estratto si passa a Gate:
- il campo termValue se lavoriamo con la tabella dcmi
- il campo fieldValue se lavoriamo con la tabella optionalfield
A questo punto Gate estrae, se presenti, i nomi di persona.
- Per ogni nome individuato da Gate, Hibernate si occupa di aggiornare le seguenti due tabelle:
- occurrencesNames che ha come schema: [axoid, tabid, recordid, field, NID, dataEstrazione], dove:
- se lavoriamo con la tabella dcmi : tabid="dcmi", recordid={campo id della tabella dcmi}, field={termRefinement in dcmi relativo al record elaborato}
- se lavoriamo con la tabella optionalfield : tabid="optionalfield", recordid={campo id della tabella optionalfield}, field={fieldName in optionalfield relativo al record elaborato}
- representationsName che ha come schema: [NID, Value, representativeNID], dove: NID sta per Name-Identifier ed è l'ID univoco per ogni valore estratto (se nella fase di estrazione dei nomi occorre più volte lo stesso valore, in questa tabella comparirà un solo record relativo), Value è la stringa che contiene il nome, representativeNID è il NID del nome rappresentante per tale record ( All'inizializzazione representativeNID=NID, successivamente sarà l'amministratore a stabilire il rappresentante per ogni persona e confermerà o meno la sinonimia proposta dall'algoritmo di similitudine, vedi Fase 2). A livello implementativo, se representativeNID= -1 allora non ha rappresentante (e quindi è rappresentato da se stesso). Quindi un nome è rappresentante se ha representativeNID=-1 (oppure se representativeNID=NID).