Nano Hash - криптовалюты, майнинг, программирование

Индексировать XML-атрибуты вместе с обычным текстом в CLucene

Мне удалось скомпилировать проект CLucene на iOS, и в настоящее время я пытаюсь использовать его в своем приложении для iOS. Я пытаюсь индексировать документы xhtml и смог сделать это, извлекая текстовые узлы из этих документов, а затем индексируя в lucene, объединяя их вместе, чтобы весь текст из одного документа xhtml отображался в одном Документ Люсен.

Однако каждый текстовый узел моего документа xhtml имеет настраиваемые атрибуты, поэтому при выполнении поиска в проиндексированном тексте я также должен иметь возможность получить атрибут, связанный с этим текстом.

Мои данные xml выглядят так:

<span data-value="/1/2/3">This is a sample text for this span</span>
<span data-value="/2/3/4">This is a example text for another span</span>
<span data-value="/3/4/5">Searching for this span text</span>

Поэтому, когда я ищу в индексе Lucene образец слова, я должен иметь возможность получить значение данных, связанное со словом Sample. В приведенном выше случае это будет data-value="/1/2/3".

Я создаю индекс путем объединения атрибута значения данных и поля текстового узла вместе, а затем индексирует его с помощью Lucene. Таким образом, всякий раз, когда мои результаты поиска возвращаются, они также будут возвращать атрибутивное значение данных вместе с ним. Я могу оценить значение атрибута, и во время поиска вообще удалю этот атрибут из результатов отображения. Однако это неверно для большого текста, содержащегося в тексте диапазона, где в искомом слове (словах) может быть возвращено, но атрибуты значения данных могут не быть частью результатов поиска, которые могут быть дополнительно удалены при отображении.

Однако я думаю, что это не оптимальный способ индексации XML-атрибутов вместе с их текстовыми данными.

Я был бы признателен, если бы кто-нибудь помог мне с подходом, чтобы индексировать отношения между текстом и его атрибутами.

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

Спасибо и с уважением, Ашиш


Ответы:


1

Если вы хотите сохранить весь текст XHTML в виде одного документа Lucene, возможно, полезной нагрузкой будет полезная нагрузка.

Альтернативный подход заключается в создании поля идентификатора документа (например, «documentID: 42» и поля, обозначающего, что этот документ Lucene представляет собой весь документ, объединенный вместе (например, «AllOfDocument: 42»). Это позволит вам индексировать каждый текстовый узел по отдельности и ограничить атрибуты только атрибутами для этого узла, но при этом привязать этот текстовый узел ко всему документу. При таком подходе вы можете поместить атрибуты в собственное поле в текстовом узле документа Lucene, а не использовать полезные данные. Может быть проще .

08.02.2013
  • Спасибо за ответ, Марк. Итак, вы говорите, что я должен создать два разных поля в одном документе, где первое поле (documentID:42) будет соответствовать только значению атрибута для определенного текстового узла, а другое поле (AllOfDocument :42), будет содержать этот конкретный текстовый узел, так что между текстовым узлом и значением его атрибута будет соответствие 1-1. Таким образом, у меня будет столько же полей для обоих в одном документе lucene, сколько текстовых узлов в документе XHTML. Означает ли это также, что один документ xhtml равен одному документу lucene. 08.02.2013
  • Также, чтобы подтвердить, когда вы имеете в виду весь текст XHTML как один документ lucene, вы имеете в виду, хочу ли я индексировать все текстовые узлы в одном документе XHTML. Это правильно? Если да, то да, я хочу проиндексировать весь текст в документах xhtml и чтобы каждый текстовый узел был привязан к своему значению атрибута. 08.02.2013
  • Я имел в виду индексировать каждый текстовый узел отдельно как документ Lucene, а также индексировать все текстовые узлы из файла XHTML как отдельный документ Lucene, который вы связываете вместе с документами Lucene текстового узла (поскольку documentID:42 и allOfDocument:42 имеют то же значение 42. 08.02.2013
  • Спасибо за ответ, Марк. Просто хотел убедиться, что я правильно понял. Итак, вы говорите, что нужно иметь три разных документа, где каждый атрибут для текстового узла, например data-value=/1/2/3, будет входить в свое собственное поле в документе, а затем будет еще одно поле только с текстовым узлом Это образец ... в другом документе, а затем в другом документе будет просто весь текст, содержащий (текст1 текст2 текст3)? Но не думаете ли вы, что это будет дублирование данных? Кроме того, каковы будут результаты поиска для моего слова Sample, которое также необходимо выделить? 08.02.2013
  • Да, вы бы дублировали документы. Если ваш вариант использования может обрабатывать все атрибуты для файла XHTML вместе, вы можете создать значение поля для каждого атрибута, прикрепленного к документу Lucene, для всего файла XHTML (и индексировать только весь файл XHTML как документ Lucene) — - но вы теряете связь между атрибутом и отдельным текстовым узлом. 08.02.2013
  • Спасибо, Марк. Да, я хочу попробовать этот подход, но я думаю, что полезная нагрузка является оптимальным решением, но требует больше работы. Я не уверен, правильно ли CLucene поддерживает полезную нагрузку. Я пробовал модульный тест для тестирования полезной нагрузки, но он дает сбой, поэтому мне придется немного покопаться, чтобы попытаться использовать полезную нагрузку с CLucene. Я также обнаружил, что в CLucene нет метода payloadTermQuery, который обычно используется для получения результатов запросов, в которые встроены полезные данные. Есть ли у вас какие-либо предложения по использованию пейлоадов? 09.02.2013
  • давайте продолжим это обсуждение в чате 09.02.2013
  • Марк, я пошел дальше и использовал подход добавления каждого текстового узла и его последующего атрибута в отдельный документ, так что теперь все мои текстовые узлы связаны с соответствующими атрибутами. Единственная обратная сторона заключается в том, что существует множество документов, содержащих всего два поля (текстовый узел и его атрибут), но с учетом требований, которые у меня есть, мне пришлось пойти по этому пути. Я бы все же предпочел использовать пейлоады, но так как я использую CLucene, поддержка пейлоадов в нем еще не полная. Я бы точно попробовал подход с полезной нагрузкой, хотя когда-нибудь позже. 14.02.2013
  • Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..