Моделирование отношения свойств класса json-LD

Question

Я пытаюсь найти лучший способ моделирования отношения собственности/класса с JSON-LD. Я пытаюсь поддерживать классы, которые могут делиться свойствами.

В первом примере используется то, что, по моему мнению, является распространенным способом достижения этого (хотя schema.org использует размещенное свойство http://schema.org/domainIncludes вместо домена rdfs:).

Однако я думаю, что мой случай использования будет лучше описать, указывая на свойства из класса, как в примере 2.

Ex 1) См ИСС: домен в свойствах.

{ 
    "@context": { 
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", 
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#", 
    "xsd": "http://www.w3.org/2001/XMLSchema#", 
    "project": "http://wwww.hello.com#" 
    }, 
    "@graph": [ 
    { 
     "@id": "project:ClassOne", 
     "@type": "rdfs:Class", 
     "rdfs:label": "ClassOne" 
    }, 
    { 
     "@id": "project:ClassTwo", 
     "@type": "rdfs:Class", 
     "rdfs:label": "ClassOne" 
    }, 
    { 
     "@id": "project:propertyOne", 
     "@type": "rdf:Property", 
     "rdfs:label": "propertyOne", 
     "rdfs:range": "xsd:string", 
     "rdfs:domain": [ 
     { "@id":"project:ClassOne" }, 
     { "@id":"project:ClassTwo" }, 
     ] 
    }, 
    { 
     "@id": "project:PropertyTwo", 
     "@type": "rdf:Property", 
     "rdfs:label": "PropertyTwo", 
     "rdfs:range": "xsd:string", 
     "rdfs:domain": [ 
     { "@id":"project:ClassOne" } 
     ] 
    } 
    ] 
} 

Ex 2) Вместо использования доменов по свойствам укажите свойства из классов. Используйте ref: isDefinedBy или project: custom/propertyList как два возможных способа. Я бы использовал один или другой, а не оба.

{ 
    "@context": { 
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#", 
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#", 
    "xsd": "http://www.w3.org/2001/XMLSchema#", 
    "project": "http://wwww.hello.com#" 
    }, 
    "@graph": [ 
    { 
     "@id": "project:ClassOne", 
     "@type": "rdfs:Class", 
     "rdfs:label": "ClassOne", 
     "rdfs:isDefinedBy": [ 
     { "@id":"project:propertyOne" }, 
     { "@id":"project:propertyTwo" } 
     ] 
    }, 
    { 
     "@id": "project:ClassTwo", 
     "@type": "rdfs:Class", 
     "rdfs:label": "ClassOne", 
     "project:custom/propertyList": [ 
      { "@id":"project:propertyTwo" } 
     ] 
    }, 
    { 
     "@id": "project:propertyOne", 
     "@type": "rdf:Property", 
     "rdfs:label": "propertyOne", 
     "rdfs:range": "xsd:string" 
    }, 
    { 
     "@id": "project:propertyTwo", 
     "@type": "rdf:Property", 
     "rdfs:label": "propertyTwo", 
     "rdfs:range": "xsd:string" 
    } 
    ] 
} 

Имеет ли это смысл, или я вообще чего-то не хватает? Причина, по которой я не хочу использовать домен в свойствах, заключается в том, что я пытаюсь создать фреймворк, в котором классы из разных «проектов» могут делиться свойствами, и не имеет смысла, чтобы свойство в проекте1 имело домен класс в проекте2.

Однако имеет смысл использовать класс в проекте1 для использования свойства в проекте2.

Answer 1

Большинство людей, работающих в словарях RDFS/OWL, имеют тенденцию моделироваться в Turtle или RDF/XML, но JSON-LD - прекрасный способ сделать это.

Что нельзя сказать о rdfs: domain (и rdfs: range) является то, что если используются два или более классов, вы фактически создаете пересечение, а не объединение; это два сущностных вывода RDFS. Когда у вас есть экземпляр, который использует свойствоOne, он автоматически сообщает, что этот экземпляр является подклассом всех его доменов (и эти значения являются подклассами всех диапазонов). Вот почему была создана схема: domainIncludes, но у нее нет формальных правил вывода.

Другим способом моделирования является использование owl: unionOf, так что вы можете сказать, что домен является подклассом класса, который является объединением двух или более других классов, но это довольно сложно, что опять же является причиной schema.org решила пойти в другом направлении.

В примере два вы, кажется, предлагаете другой способ описания словаря. Обратите внимание, что rdfs: isDefinedBy также имеет определенное значение, и я не видел его использовать для описания отношений свойств раньше. Конечно, структурно, вы можете включить определения свойств как в ClassOne, так и в ClassTwo, используя @reverse. Ключевым моментом является поиск троек, которые он создает, поэтому Черепаха часто лучше подходит для моделирования словарного запаса или Protégé для создания цели. Как только это будет сделано, вы можете сериализоваться как JSON-LD, возможно, используя некоторые обрамления, чтобы создать интересующую вас структуру.