Создание электронной таблицы из файла XML - PullRequest
1 голос
/ 30 марта 2010

Я пытаюсь преобразовать 120-мегабайтную XML-базу данных о террористических инцидентах (первый файл для скачивания доступен здесь http://wits.nctc.gov/Export.do) в электронную таблицу, чтобы я мог объединить ее с другими данными и выполнить статистический анализ.

До сих пор я работал со Stata, который сейчас бесполезен, потому что он не читает XML. сайт предлагает файлы меньшего размера по месяцам, которые можно открывать с помощью Excel, но Excel не отображает их в нужной форме, и должен быть лучший способ преобразовать весь файл, а не открывать более ста отдельных файлов, сохраняя их вручную как вкладка разделена, а затем объединить их.

Я ищу способ преобразования полного файла WITS.xml в электронную таблицу, в которой одна строка представляет отдельный террористический инцидент, и никакая информация из XML не должна отсутствовать. даже XML с другой структурой, вероятно, подойдет. Я пробовал конвертеры, но они либо не бесплатны, либо не работают так, как мне нужно, либо размер файла слишком велик, и я понятия не имею, как использовать xslt. Я изучаю экономику, и мои знания по программированию практически отсутствуют, что все больше становится недостатком. Я видел, что есть пакет для R, который я мог бы использовать, возможно, сейчас подходящий момент, чтобы начать изучать R или какой-то другой язык. Однако, если есть быстрый и простой способ сделать это, я бы предпочел его.

Ответы [ 2 ]

5 голосов
/ 30 марта 2010

Вам, как правило, требуется больше помощи с концепциями XML, чем с конкретными пакетами R и фрагментами для работы с файлами XML (хотя это может произойти позже ;-)). Также может оказаться предпочтительным преобразовать входной файл в более приемлемый формат до , используя его в R, Stata или других статистических инструментах.

В целях иллюстрации я воспроизвожу ниже первую запись <incident> из источника, упомянутого в вопросе. Можно предположить, что другие инциденты будут иметь аналогичную структуру. Посмотрев файл DTD, мы могли бы утверждать, содержит ли корень другие узлы («записи»), отличные от <incidents>, и имеют ли эти инциденты точно такую ​​же структуру (или, например, если некоторые типы инцидентов могут иметь дополнительные, скажем, Узел <LocalWeatherConditions>, или, если, скажем, узел <facilityList> является необязательным). Для целей этого обсуждения можно предположить, что все записи о происшествиях имеют одинаковую общую структуру.

Ваш запрос " электронной таблицы, где одна строка представляет один террористический инцидент, и никакая информация из xml должна отсутствовать " может быть затруднена из-за проблем с количеством элементов. Это причудливый способ сказать, что некоторые подэлементы записей об инцидентах могут повторяться. Например, большинство узлов, чье имя оканчивается на «Список», обычно может содержать более одной вложенной записи (кстати, этот «Список в имени» не является правилом XML, это просто соглашение, которое хранители этой конкретной базы данных используют) , Например, может быть несколько <CityStateProvince> записей, каждая со своими собственными значениями для City и StateProvince, или может быть несколько `записей, каждая со своим длинным списком значений.
Можно «сгладить» данные в одну строку. Общий процесс - это «денормализация», при которой одна строка включает столбцы с пронумерованными метками:

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

Кроме того, помимо получения широких записей, которые, возможно, превышают (абсолютные или практические) пределы базового языка, этот формат очень громоздок в отношении агрегирования и выполнения статистики в целом: скажем, вы хотите получить подсчет с помощью StateProv: Теперь вам нужно дать команду программе «просмотреть» все возможные места, где находится эта информация: «StateProv1», «StateProv2» ...

Альтернативным форматом, более подходящим для статистической обработки, является экспорт в несколько «электронных таблиц». при этом основная электронная таблица содержит одну строку для каждого инцидента для всех неповторяемых свойств записи инцидента, а дополнительные электронные таблицы содержат «вспомогательные записи», которые могут повторяться. Эти вложенные записи должны включать «ключ», который можно использовать для связи с базовой записью в основной электронной таблице (здесь, вероятно, ICN), и они могут также включать дублированную информацию из основной электронной таблицы, например, внесение IncidateDate , флаг Ассанинации и т. д. Цель этой денормализации [другого рода] состоит в том, чтобы сделать эту дополнительную электронную таблицу самодостаточной для некоторого целевого анализа.

Куда пойти оттуда?

  • Вам необходимо определить точный формат для таблиц, которые будут созданы из входных данных XML.
    Вы, вероятно, согласитесь с тем фактом, что подход с пронумерованными метками нецелесообразен, и, следовательно, вам нужно будет просмотреть входные данные и посмотреть, как вы хотите их разделить (опять же, с возможностью репликации данных).
  • Вы можете использовать R, например, этот XML-пакет , чтобы проанализировать входные данные в переменные R (таблица, списки, векторы ...)
  • В качестве альтернативы, вы можете (я думаю, следует) использовать внешнюю программу, чтобы выполнить этот экспорт XML-ввода в табличную форму (формат CSV и т. П.), Который более легко принимается R.
    Хотя я использую упомянутый пакет XML, для небольших файлов (и в основном для целей вывода), я боюсь, что он может быть неэффективным, подверженным ошибкам (у вас нет возможности легко проверить эффективный ввод, как это можно сделать с помощью текстового файла). ) и вообще неуклюжий.

К счастью, вы скоро сможете закончить эту работу по конвертации / импорту и сосредоточиться на имеющейся статистике!

Несколько заключительных указателей:

  • Даже если вы не совсем понимаете язык DTD, взгляните на файл XTD, в частности на множество списков <xs:enumeration ...>, которые составляют основную часть файла, поскольку они предоставят вам коэффициент ( в R lingo) значения. Конечно, R также может вывести их из данных, но вы можете использовать информацию из перечислений для перекрестных ссылок (чтобы убедиться, что данные были априори загружены правильно и т. Д.)

  • Вероятно, можно выводить схему из нескольких образцов записей (люди, незнакомые с XML, могут легче понять данные XML, чем файлы XSD). Однако, чтобы быть уверенным, нужно прочитать файл 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>
1 голос
/ 30 марта 2010

Я начал использовать продукт с открытым исходным кодом под названием Talend Open Studio для выполнения таких задач извлечения / преобразования / загрузки. Это инструмент для генерации кода на основе графического интерфейса, который выводит данные на переносимый Perl или Java и поставляется с миллиардами соединений с базами данных и типами файлов.

Это потребует обучения; не совсем интуитивно понятно выполнять некоторые более сложные задачи. Однако я подозреваю, что его настройка для чтения вашего XML и вывода в XLS будет довольно быстрой и простой.

...