Вопрос или проблема
Используя единицы QUDT в течение некоторого времени в различных графах данных RDF и онтологиях в прошлом, я хотел бы лучше понять лучшие практики для этого, поскольку сам QUDT не предоставляет хороших примеров.
Мне особенно любопытно истинное значение и способ использования QuantityKinds.
Пока что я рассматривал способ моделирования свойства, если вы знаете его единицу, следующим образом.
ex:speedInRPM a sh:PropertyShape ;
sh:path <http://purl.allotrope.org/ontologies/property#AFX_0000211> ;
sh:property [sh:path qudt:unit ; sh:hasValue unit:REV-PER-MIN ; sh:minCount 1] ;
sh:property [sh:path qudt:value ; sh:minCount 1 ]
.
Данные экземпляров тогда будут выглядеть следующим образом:
ex:thingThatRotates <http://purl.allotrope.org/ontologies/property#AFX_0000211>
[qudt:unit unit:REV-PER-MIN ; qudt:value "3200"]
Я также рассматривал другой сценарий, где онтология менее специфична в отношении того, какая единица необходима, чтобы данные считались действительными. Например, “Плотность”. Смотря на определение плотности в qudt (https://qudt.org/vocab/quantitykind/Density), это звучит очень похоже на свойство (но это не так, это экземпляр qudt:QuantityKind – так что по крайней мере это некий “объект”?)
Здесь я хочу использовать лучшую практику (или стандарт) для моделирования требования о том, что единица должна быть экземпляром quantityKind. Я полагаю, что мне нужно создать новое свойство, как ex:density, которое ограничено quantityKind qudt:Density. Однако я хочу избежать чрезмерного усложнения своей модели – мне нужно только строгое минимальное количество троек, необходимое для выполнения базовой валидации SHACL, которая проверяет, является ли указанная единица для определенного свойства действительной.
ex:densityShape a sh:PropertyShape ;
sh:path ex:density ;
sh:property [sh:path qudt:unit ; sh:class qudt:Density ; sh:minCount 1] ;
sh:property [sh:path qudt:value ; sh:minCount 1 ]
.
Мне любопытны мнения о вышеизложенном. Если я читаю qudt, это кажется действительным способом сделать это, но я ищу опыт/примеры других, использовавших qudt для чего-то подобного.
Спасибо!
Ответ или решение
Лучшие практики моделирования свойств с единицами измерения с использованием QUDT
Вопрос о моделировании свойств с единицами измерения в контексте QUDT (Quantities, Units, Dimensions, and Types) становится все более актуальным благодаря возрастающей сложности данных и необходимости обеспечения их семантической согласованности. В этом ответе мы рассмотрим лучшие практики и методы, которые помогут вам эффективно использовать QUDT в ваших RDF-графах и онтологиях.
1. Понимание QuantityKind
QuantityKind в QUDT представляет собой абстрактное представление определенных физических или математических понятий, таких как плотность, скорость и т.д. Каждый QuantityKind служит категорией, к которой могут относиться конкретные единицы измерения. Это означает, что при моделировании свойств, связанных с величинами, следует учитывать QuantityKind как способ описания требований к единицам измерения.
Пример использования QuantityKind:
ex:density a sh:PropertyShape ;
sh:path ex:density ;
sh:property [sh:path qudt:unit ; sh:class qudt:Density ; sh:minCount 1] ;
sh:property [sh:path qudt:value ; sh:minCount 1 ] .В этом примере мы создаем свойство ex:density, которое ожидает, что для него будет указана единица измерения, относящаяся к концепту Density из QUDT. Это позволяет проверить, что вводимые данные являются семантически корректными.
2. Моделирование свойств с известными единицами
Для свойств, где единицы измерения известны заранее, ваша модель может выглядеть следующим образом:
ex:speedInRPM a sh:PropertyShape ;
sh:path <http://purl.allotrope.org/ontologies/property#AFX_0000211> ;
sh:property [sh:path qudt:unit ; sh:hasValue unit:REV-PER-MIN ; sh:minCount 1] ;
sh:property [sh:path qudt:value ; sh:minCount 1 ] .Здесь ex:speedInRPM определяет, что значение скорости должно быть представлено в оборотах в минуту (REV-PER-MIN), что обеспечивает строгую валидацию ввода.
3. Гибкость в определении единиц измерения
Когда требуется гибкость в определении единиц измерения, особенно для QuantityKind таких, как плотность, вы можете рассмотреть возможность создания общего свойства и его валидации через SHACL:
ex:densityShape a sh:PropertyShape ;
sh:path ex:density ;
sh:property [sh:path qudt:unit ; sh:class qudt:Density ; sh:minCount 1] ;
sh:property [sh:path qudt:value ; sh:minCount 1 ] .Таким образом, при указании единицы измерения для свойства ex:density вы можете убедиться, что она соответствует классу Density из QUDT.
4. Минимализм в модели
Минимализм в количестве используемых триплетов — это хороший подход, который позволяет избежать излишней сложности. Вам не нужно создавать множество дополнительных свойств, если вы можете использовать существующие классы и свойства QUDT. Однако во время проектирования убедитесь, что каждая часть вашей модели выполняет четко определенную задачу и согласуется с требованиями вашего проекта.
5. Валидация и применение SHACL
SHACL (Shapes Constraint Language) предоставляет мощные возможности для валидации данных в RDF и позволяет установить четкие правила для того, как ваши данные должны выглядеть. Использование PropertyShapes, как обсуждено выше, поможет вам гарантировать, что данные, которые вы вводите, соответствуют установленным стандартам качества и семантики.
Заключение
Использование QUDT для моделирования свойств с единицами измерения — это многообещающая практика, которая обеспечивает структурированность и семантическую точность ваших данных. Понимание и применение QuantityKind, создание строгих правил SHACL для валидации и работа с минималистичными моделями являются ключевыми аспектами успешного использования QUDT. Надеюсь, что предложенные рекомендации помогут вам в вашей работе с RDF данных и онтологиями.