Насколько практичны онтологии единиц измерения в RDF? - PullRequest
Новая
       11

Насколько практичны онтологии единиц измерения в RDF?

3 голосов
/ 05 февраля 2020

Я создаю коллекцию материалов в RDF. Я столкнулся с двумя подходами к обработке единиц измерения:

  1. Связав описательное имя со свойством RDF: 
     prop:density prop:hasUnits "kg/m3". 

     <x:MyBrick> a x:Material;
     prop:density "1676".`
Использование существующей библиотеки онтологий, такой как онтология единиц измерения . Гораздо сложнее назначать юниты, так как для этого необходимо создать несколько объектов . Ниже показано, как я присвоил материалу одинаковую плотность: 
 <x:MyBrick> a x:Material;
om:hasPhenomenon <x:density_MyBrick>.

 <x:density_MyBrick> a om:Density;
  om:hasValue <x:1676_kilogramspercubicmetre>.

<x:1676_kilogramspercubicmetre> a om:Measure;
  om:hasNumericalValue 1.676E3;
  om:hasUnit om:kilogramPerCubicmetre .

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

Я предпочитаю использовать 1-й подход. Это намного чище, гибче и предоставляет пользователю полезную информацию, которая иначе не была бы доступна в типичной базе данных. Я бы попытался обработать преобразования единиц на стороне приложения, поэтому моим приоритетом было бы хранение информации удобным для запросов способом. Меня беспокоит то, что, приняв этот подход, я буду ограничивать функциональность в дальнейшем. Есть ли основные преимущества и недостатки выбора одного подхода по сравнению с другим?

1 Ответ

2 голосов
/ 07 февраля 2020

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

Что касается второго подхода, упомянутого в этом вопросе, можно подумать, что совершенно неестественно писать с использованием промежуточных объектов. Однако онтологии для описания измерений вещей могли быть написаны с учетом нескольких аспектов. Например, в случае, когда что-то расширяется в конкретный момент, могут потребоваться промежуточные объекты, чтобы указать время этих измерений. Конечно, существуют ситуации, когда эти дополнительные описания не требуются.

Проблема с первым подходом состоит в том, что он полностью ограничивает prop:density только одной единицей. Если у вас есть плотность в другой единице, вам придется выполнять преобразования.

Я думаю, что простое решение в вашем контексте - это ввести конкретные c типы данных. 

@prefix x:  <http://example.com/data> .
@prefix o:   <http://example.com/ontology> .

x:MyBrick a x:Material;
     o:density "1676"^^o:kg-m3.

В вашей онтологии с IRI http://example.com/ontology вы можете более подробно описать ресурс o:kg-m3. Например, вы можете сказать, что это тип данных для плотности типов, измеряемый в килограммах на кубический метр c, следующим образом: 

@prefix o:   <http://example.com/ontology> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

o:kg-m3 a rdfs:Datatype;
        rdfs:label "Kilogram per metric cube datatype (kg/)";
        rdfs:comment "A datatype to type densities measured in kilogram per meter cube" .

o:kg-l a rdfs:Datatype;
        rdfs:label "Kilogram per liter datatype";
        rdfs:comment "A datatype to type densities measured in kilogram per liter cube" .

Как вы можете видеть выше, был определен дополнительный тип данных o:kg-l. Теперь, используя одно и то же свойство, вы можете указать плотности, измеренные в разных единицах. Например: 

@prefix x:  <http://example.com/data> .
@prefix o:   <http://example.com/ontology> .

    x:MyBrick1 a x:Material;
         o:density "1676"^^o:kg-m3.

    x:MyBrick2 a x:Material;
         o:density "200"^^o:kg-l.

    x:MyBrick3 a x:Material;
         o:density "200a"^^o:kg-m3.

Как вы можете видеть выше, три экземпляра x:Material и их соответствующие o:density были определены. Глядя на вышеупомянутые тройки, вы заметите, что в последней тройке значение o:density равно 200a. Вы согласитесь, что значение не является правильно сформированным значением плотности. Кроме того, вы можете узнать, какие объекты, x:MyBrick1 или x:MyBrick2, имеют более высокую плотность. Соответствующее хранилище триплетов RDF не сможет распознать, что значение в последней тройке неправильно сформировано. Аналогичным образом, совместимый механизм SPARQL не сможет выполнять алгебраические операции c со значениями o:density. Тем не менее, вы можете настроить реализацию триплет-хранилища RDF или движка SPARQL в соответствии с этими потребностями. В этой статье [1] описывается, как этого добиться.

  1. Лефрансуа, Максим и Антуан Циммерманн. «Поддержка произвольных пользовательских типов данных в RDF и SPARQL». European Semanti c Веб-конференция. Springer, Cham, 2016. (https://www.emse.fr/~zimmermann/Papers/eswc2016.pdf)
...