json-LD 클래스 속성 관계 모델링

Question

JSON-LD와 속성/클래스 관계를 모델링하는 가장 좋은 방법을 찾으려고합니다. 속성을 공유 할 수있는 클래스를 지원하려고합니다.

첫 번째 예제는 이것을 달성하는 일반적인 방법이라고 생각합니다 (schema.org는 rdfs : 도메인 대신 http://schema.org/domainIncludes이라는 호스팅 된 속성을 사용하지만). 속성 도메인 :

그러나 나는 내 사용 사례가 더 나은 2.

예 1) RDFS를 참조 예와 같이 클래스의 속성을 가리키는에 의해 설명 될 것이라고 생각합니다.

{ 
    "@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" } 
     ] 
    } 
    ] 
} 

예 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" 
    } 
    ] 
} 

뭔가 의미가 있습니까? 왜냐하면 나는 다른 '프로젝트'의 클래스가 속성을 공유 할 수있는 프레임 워크를 구축하려고하기 때문에 속성에 도메인을 사용하지 않기 때문에, project1의 속성이 프로젝트 2의 클래스.

그러나 project1의 클래스는 project2의 속성을 사용하는 것이 좋습니다.

Answer 1

RDFS/OWL 어휘로 작업하는 대부분의 사람들은 거북이 또는 RDF/XML로 모델링하는 경향이 있지만 JSON-LD는이를 수행하는 좋은 방법입니다.

rdfs : domain (및 rdfs : range)에 대해 종종 이해하지 않는 것은 두 개 이상의 클래스가 사용되는 경우 실제로는 공용체가 아니라 공용체를 생성한다는 것입니다. 이것은 RDFS의 추론 성격의 두 가지입니다. propertyOne을 사용하는 인스턴스가 있으면 해당 인스턴스가 모든 도메인의 하위 클래스이고 그 값이 모든 범위의 하위 클래스라는 것을 자동으로 추론합니다. 이것이 스키마 : domainIncludes가 생성되었지만 공식 유추 규칙이없는 이유입니다.

owl : unionOf를 사용하여 도메인이 두 개 이상의 다른 클래스의 합집합 인 클래스의 하위 클래스라고 말할 수있는 또 다른 모델을 만들 수 있습니다. 그러나 이것은 매우 복잡하며 이는 다시 schema.org는 다른 방향으로 가기로 결정했습니다.

예 2에서는 어휘를 설명하는 다른 방법을 제안하는 것처럼 보입니다. rdfs : isDefinedBy는 또한 특별한 의미를 가지고 있으며, 이전에 속성 관계를 설명하는 것을 보지 못했습니다. 물론 구조적으로 ClassOne과 ClassTwo에서 @reverse를 사용하여 속성 정의를 포함 할 수 있습니다. 핵심은 그것이 생성하는 트리플을보고 있습니다. 따라서 터틀은 종종 어휘 모델링이나 목적으로 프로 테지를 만들기에 더 적합합니다. 완료되면 JSON-LD로 직렬화 할 수 있습니다. 관심있는 구조를 만들기 위해 프레임을 사용하는 것이 가능할 수 있습니다.