Я не знаю стандартного способа сделать это, но одно из преимуществ работы в RDF заключается в том, что у вас есть большая гибкость в том, как вы решили это сделать. RDF, per se, не может выразить отрицание (т. Е. Нет невероятно удобного способа сказать, что тройка s p o не выполняется), но OWL может. Что касается четырех случаев descibed, вот некоторые подходы, которые вы можете сделать:
1. Значение не применяется, то есть свойство р не существует, или не имеет смысла в контексте.
Если это не имеет особого смысла для свойства р быть иметь значение для субъекта ов, то это, вероятно, приемлемо, чтобы просто не писать никаких троек вида SPO , Поскольку RDF делает предположение о открытом мире, часто бывает так, что при извлечении данных запрашиваются только те данные, которые заинтересованы, и не делает слишком много усилий, чтобы проверить, где есть неожиданные вещи. Если вы хотите выполнить некоторую проверку работоспособности, вы можете объявить домены и диапазоны RDFS для свойств. Например, вы могли бы:
hasBirthDate rdfs:domain AnimateObject .
hasConstructionDate rdfs:domain InanimateObject .
Согласно семантике, если вы затем
object82 hasBirthDate "2013-04-01" ;
hasConstructionDate "2013-04-02" .
тогда вы будете также сделать вывод, что
, и вы можете запустить здравомыслие проверьте, что ищет вещи, которые являются как AnimateObject s, так и InanimateObject s. Если что-то и так, у вас, вероятно, есть проблема, над которой вам стоит заглянуть. Если вы используете OWL, вы можете фактически заявить, что AnimateObject и InanimateObject не пересекаются и проверяют логическую согласованность.Кроме того, в OWL, вы можете добавить утверждения, такие как
object82 hasConstructionDate max 0
, который говорит, что object82 не должны иметь значения для свойства hasConstructionDate.
В любом случае, добавьте rdfs:comment s к своим свойствам, объясняя, для чего необходимо использовать свойство и для чего его не следует использовать. При необходимости добавьте rdfs:comment s лицам, чтобы объяснить, почему они не должны иметь значение для данного свойства, если они не должны иметь такое значение.
2. Значение неизвестно, то есть оно должно быть там, но мы этого не знаем.
В этом случае важно указать, что именно означает «должно». В OWL, к примеру, вы можете сказать, что
Person SubClassof (hasName min 1 String)
утверждать, что каждый person связан, по меньшей мере, один String по собственности hasName; то есть у каждого человека есть хотя бы одно имя. Это один из способов сказать, что имеет значение, но мы можем не знать, что это такое в конкретном случае. Если вы не можете работать с OWL, но только с RDF, то вы, вероятно, следует добавить rdfs:comment свойству hasName вдоль линий «каждого NamedEntity должны иметь по крайней мере одно значение для этого свойства.»
3. Значение не существует, т. Е. Свойство не имеет значения (например, год смерти для живого человека).
Это интересный случай, потому что RDF имеет встроенного в понятие времени (в том смысле, что некоторые тройная приёмы до определенного времени, и после чего некоторые другие тройная держит). Если вы просто используете RDF-граф в качестве хранилища базы данных, который вы можете обновить (как путем удаления, так и вставки новых троек), возможно, вы можете использовать какое-то специальное зарезервированное значение для “I'm not dead yet!”. Имея открытую законченную модель данных, как мы делаем в RDF, делает его особенно легко сделать что-то вроде этого, потому что вы действительно можете просто использовать некоторые новые значения для него:
mp:JohnCleese hasDeathDate mp:notDeadYet .
mp:GrahamChapman hasDeathDate "1989-10-04" .
Конечно, вы можете также быть немного более изощренные и использовать свойство булевозначного указать, имеет ли или нет значения для первого свойства смысла:
mp:JohnCleese isDeceased "false" .
mp:GrahamChapman isDeceased "true" ;
hasDeathDate "1989-10-04" .
4. значение удерживается, например, когда потребитель данных не допускаются для доступа к нему.
Это, на мой взгляд, самый интересный случай, поскольку он потенциально связан с наиболее интересным преобразованием данных. Если у вас есть хороший набор данных, который люди могут запросить, и вы хотите указать что-то о результатах, которые они получили бы, кроме их отсутствия разрешения, у вас есть много вариантов в представлении этого. Например, вы могли бы использовать что-то вроде кодов состояния HTTP для замены узлов в графе пустыми узлами, действующими подобно редактированию.Например, вы могли бы иметь данные:
ex:JohnDoe hasSSN "000-00-0000" .
ex:JaneDoe hasSSN "000-00-0001" .
Когда кто-то запрашивает данные, вы можете ответить (если предположить, что первое значение является действительным, а второй один недействительный):
ex:JohnDoe hasSSN [ a ex:ValidSSN ] .
ex:JaneDoe hasSSN [ a ex:InvalidSSN ] .
В в общем, вы могли бы представить другой взгляд на данные для потребителей, чем то, что вы на самом деле имеете. Я не знаю никаких стандартов для такого рода вещей. Вас может заинтересовать недавняя рекомендация W3C от PROV-O: The PROV Ontology, словарь для описания происхождения информации (например, от того, от чего она была создана, от того, что она отнесена); это может быть полезно при описании видов ресурсов, которые могут быть недоступны в их полной форме для запрашивающих.
Я думаю, что этот вопрос станет отличным примером вопроса о [Предложение Semantic Web] (http://area51.stackexchange.com/proposals/53218/semantic-web?referrer=GMMTsbTUwV511mI2mO2k0g2). Может быть, вы хотите добавить его? – unor
@unor Done, спасибо за подсказку – Mifeet
Цитата: «NULL используется в базах данных». Вы имеете в виду NULL, как используется в * SQL * базах данных или какой-либо другой концепции NULL? SQL-стиль NULL не различает различные случаи, перечисленные здесь, поэтому все, что вы хотите, - это * не * эквивалент NULL в базе данных SQL. NULL в стиле SQL - это катастрофа. Не было бы смысла имитировать ошибки SQL в RDF. – sqlvogel