Creazione di un foglio di calcolo da un file XML

Question

Sto cercando di convertire un database 120MB XML di attentati terroristici (il primo file disponibile per il download qui http : //wits.nctc.gov/Export.do ) a forma di foglio di calcolo in modo che possa fondersi con altri dati e fare analisi statistiche

.

Finora ho lavorato con Stata, che è inutile ora, perché non ci vorrà leggere il codice XML. il sito offre i file più piccoli per mese che possono essere aperti tramite Excel, ma eccellere non li visualizza in forma che voglio e ci dovrebbe essere un modo migliore per trasformare il file completo, piuttosto che aprire oltre un centinaio di singoli file, salvandoli manualmente come scheda separata e successivamente la loro unione.

Sto cercando un modo per convertire il file WITS.xml completa ad un foglio di calcolo in cui una riga rappresenta un singolo episodio di terrorismo, e non informazioni dalla xml dovrebbe mancare. anche un XML diversamente strutturato è probabilmente bene. Ho provato convertitori ma non sono né libere, non eseguire nel modo li voglio o la dimensione del file è troppo grande, e non ho idea di come utilizzare XSLT. Sto studiando l'economia, e la mia conoscenza di programmazione è praticamente inesistente, che sta diventando sempre più uno svantaggio. Ho visto che c'è un pacchetto per R che potrei usare, forse ora è il momento giusto per iniziare R o qualche altra lingua di apprendimento. Tuttavia, se c'è un modo semplice e veloce per farlo, mi piacerebbe certamente preferisco.

Answer 1

Ti sembra di avere bisogno di più aiuto con i concetti di XML, in generale, che con pacchetti R specifici e frammenti a che fare con i file XML (anche se questo può venire dopo ;-)). Inoltre, si possono trovare preferibile convertire il file di input in un formato più appetibile prima di utilizzarlo all'interno di R, Stata o altri strumenti statistici.

Per scopi illustrativi, che sto riproducendo sotto il primo record <incident> dalla sorgente indicato nella domanda. Possiamo supporre che altri incidenti avranno una struttura simile. Osservando il file DTD, potremmo affermare che la radice contiene altri nodi ( "record") rispetto <incidents> e se questi incidenti hanno esattamente la stessa struttura (o se per esempio alcuni tipi di incidente possono avere per esempio un, diciamo, il nodo più <LocalWeatherConditions> , o se, per esempio, il nodo <facilityList> è opzionale). Ai fini di questa discussione è OK per scontato che tutti i record incidenti hanno la stessa struttura generale.

La richiesta di un " foglio di calcolo in cui una riga rappresenta un singolo episodio di terrorismo, e non informazioni dalla XML dovrebbe mancare " può essere difficile da raggiungere a causa di problemi di cardinalità. Questo è un modo elegante per dire che alcuni sotto-elementi dei record incidenti possono essere ripetuti. Per esempio la maggior parte dei nodi il cui nome termina con "List" in genere può contenere più di un sub-record di (BTW questa "lista nel nome" cosa non è una regola XML, semplicemente una convenzione i custodi di questa particolare banca dati stanno usando) . Ad esempio, ci potrebbe essere più record <CityStateProvince>, ognuno con i propri valori al di City e StateProvince, o ci potrebbero essere più `record, ognuno con la sua lunga lista di valori.
È possibile "appiattire" i dati, in un'unica fila. Il processo generale è quello di "denormalizzazione", per cui la singola fila include colonne con etichette numerate:

  ..., City1, StateProv1, City2, StateProv2, City3, StateProv3 ... (btw where do we stop?)

Inoltre, a parte che porta a larghe record che forse superano i limiti (assoluti o pratici) della lingua sottostante, questo formato è molto cumbursome per quanto riguarda l'aggregazione e l'esecuzione di statistiche in generale: Diciamo che desidera ottenere i conteggi per StateProv: è ora necessario indicare al programma di "guardare" in tutti i possibili luoghi in cui queste informazioni è trovato: "StateProv1", "StateProv2" ...

un formato alternativo, più adatto a trattamento statistico, è quello di esportare in più "fogli di calcolo". per cui un foglio principale contiene una riga per incidente per tutti i ripetibili proprietà del record incidente e fogli aggiuntivi contengono il "sub-record" non che possono ripetersi. Questi sotto-record dovrebbe includere una "chiave" che può essere utilizzata per correlare al record sottostante nel foglio di calcolo principale (probabilmente l'ICN, qui), e possono anche includere informazioni duplicato dal foglio di calcolo principale, ad esempio portando nel IncidateDate , la bandiera Assanination ecc lo scopo di questo denormalizzazione [di un altro tipo] è quello di rendere questi possibilmente foglio di calcolo di auto in più sufficiente per alcune delle analisi mirate.

Dove andare da lì?

• È necessario definire il formato preciso per il foglio di calcolo (s) per essere prodotto dalla input XML.
  È probabile che d'accordo con il fatto che l'approccio etichette numerate è impraticabile e quindi avrete bisogno di guardare i dati di input e vedere come si desidera dividerlo (ancora una volta con la possibilità di replicare i dati).
• È possibile utilizzare R per esempio questo XML per analizzare l'input in Parametri R (tavolo, elenchi, vettori ...)
• In alternativa, è possibile (credo dovrebbe), utilizzare un programma esterno, per eseguire questa esportazione degli input XML in forma tabellare (formato CSV e simili), che è più facilmente ingerito dai R.
  Anche se io uso il pacchetto XML accennato, per file di piccole dimensioni (e per lo più per scopi di uscita), I FeaR può essere inefficiente, bug prona (ti manca la capacità di ispezionare, facilmente, l'ingresso efficace, in quanto può essere fatto con un file di testo), e in generale goffo.

Per fortuna, si possa presto superare questo lavoro di conversione / importazione, e concentrarsi sulle statistiche a portata di mano!

Alcune indicazioni finali:

• Anche se non si capisce facilmente il linguaggio DTD, date un'occhiata al file XTD, in particolare le molte liste <xs:enumeration ...>, che comprendono la maggior parte dei file, in quanto questi vi fornirà il fattore (in R ) valori gergo. Naturalmente R può dedurre questi pure, dai dati, ma è possibile utilizzare le informazioni da enumerazioni per scopi riferimenti incrociati (per confermare che i dati sono stati a priori caricata correttamente, ecc)
  

• E 'probabilmente ok per dedurre lo schema da diversi campioni di record (persone che non conoscono XML possono più facilmente comprendere i dati XML di file XSD). A dire il vero però si ha la necessità di leggere il file XSD.

---

<IncidentList xmlns="http://wits.nctc.gov" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://wits.nctc.gov WITS.XSD">

<Incident>
   <ICN>200458431</ICN>
   <Subject>10 civilians killed, at least 45 wounded by suspected GAM in Peureulak, Indonesia</Subject>
   <Summary>On 1 January 2004, in Peureulak, Aceh Province, Indonesia, a bomb exploded at a concert, killing ten civilians, wounding 45 others, and causing major damage to the stage area.  Many of the victims were Indonesian teenagers.  Police blamed the Free Aceh Movement (GAM), although the GAM denied responsibility.  No other group claimed responsibility.</Summary>
   <IncidentDate>01/01/2004</IncidentDate>
   <ApproximateDate>No</ApproximateDate>
   <MultipleDays>No</MultipleDays>
   <EventTypeList>
      <EventType>Bombing</EventType>
   </EventTypeList>
   <Assassination>No</Assassination>
   <Suicide>No</Suicide>
   <WeaponTypeList>
       <WeaponType>Explosive</WeaponType>
   </WeaponTypeList>
   <IED>No</IED>
   <Location>
      <Region>East Asia-Pacific</Region>
      <Country>Indonesia</Country>
      <CityStateProvinceList>
         <CityStateProvince>
            <City>Peureulak</City>
            <StateProvince>Aceh</StateProvince>
         </CityStateProvince>
      </CityStateProvinceList>
   </Location>
   <VictimList>
      <Victim>
      <VictimType>Civilian</VictimType>
      <Combatant>No</Combatant>
      <Nationality>Indonesia</Nationality>
      <DefiningCharacteristicList>
         <DefiningCharacteristic>None</DefiningCharacteristic>
      </DefiningCharacteristicList>
      <TargetedCharacteristicList>
         <TargetedCharacteristic>Unknown</TargetedCharacteristic>
      </TargetedCharacteristicList>
      <Indicator>Targeted</Indicator>
      <Child>No</Child>
      <DeadCount>10</DeadCount>
      <WoundedCount>45</WoundedCount>
      <HostageCount>0</HostageCount>
      </Victim>
   </VictimList>
   <FacilityList>
      <Facility>
         <FacilityType>Public Place/Retail</FacilityType>
         <Combatant>No</Combatant>
         <Nationality>Indonesia</Nationality>
         <DefiningCharacteristicList>
         <DefiningCharacteristic>None</DefiningCharacteristic>
         </DefiningCharacteristicList>
         <TargetedCharacteristicList>
         <TargetedCharacteristic>Unknown</TargetedCharacteristic>
         </TargetedCharacteristicList>
         <Indicator>Targeted</Indicator>
         <Damage>Light</Damage>
         <Quantity>1</Quantity>
      </Facility>
   </FacilityList>
   <PerpetratorList>
      <Perpetrator>
         <Nationality>Indonesia</Nationality>
         <Characteristic>Secular/Political/Anarchist</Characteristic>
      </Perpetrator>
   </PerpetratorList>
</Incident>
[...]
</IncidentList>

Answer 2

Ho iniziato a utilizzare un prodotto Open Source chiamato Talend Open Studio a fare questo tipo di estratto / trasformare le attività / carico. E 'uno strumento di generazione del codice basato su GUI che emette a Perl portatile o Java, e viene fornito con gazillions di connessioni a tipi di database e file.

Ci vorrebbe una curva di apprendimento; non è del tutto intuitivo per fare alcuni dei compiti più complessi. Tuttavia, ho il sospetto che configurarlo per leggere il tuo XML e output per XLS sarebbe abbastanza facile e veloce.