시맨틱 웹 및 링크된 데이터. 수정 및 추가

나는 최근에 출판된 이 책의 일부를 대중에게 소개하고 싶습니다.

기업의 존재론적 모델링: 방법 및 기술 [텍스트]: 논문 / [S. V. Gorshkov, S. S. Kralin, O. I. Mushtak 및 기타; 편집장 S.V. Gorshkov]. - 예카테린부르크: 우랄 대학교 출판사, 2019. - 234 p.:ill., table; 20cm -저자. 가슴 뒷부분에 표시되어 있습니다. 와 함께. — 참고문헌 ch의 끝에서. — ISBN 978-5-7996-2580-1: 200부.

이 단편을 Habré에 게시하는 목적은 네 가지입니다.

• 존경받는 고객이 아닌 이상 누구도 이 책을 손에 쥐지 못할 것 같습니다. 서지인덱스; 확실히 판매되지 않습니다.
• 텍스트가 수정되었으며(아래에 강조 표시되지 않음) 인쇄된 논문의 형식과 잘 호환되지 않는 주제별 메모(스포일러 아래) 및 하이퍼링크가 추가되었습니다.
• 그러고 싶다. 질문과 의견을 수집, 다른 출판물에 이 텍스트를 개정된 형식으로 포함할 때 이를 고려하기 위해.
• 많은 시맨틱 웹 및 링크 데이터 지지자들은 여전히 ​​자신의 범위가 너무 좁다고 믿고 있습니다. 이는 주로 일반 대중이 시맨틱 웹 및 링크 데이터 지지자가 되는 것이 얼마나 좋은지 제대로 설명되지 않았기 때문입니다. 단편의 저자는 비록 이 집단에 속해 있지만 이러한 의견을 갖고 있지는 않지만 그럼에도 불구하고 자신이 또 다른 시도를 해야 할 의무가 있다고 생각합니다.

따라서,

시맨틱 웹

인터넷의 진화는 다음과 같이 표현될 수 있습니다(또는 아래 표시된 순서로 형성된 세그먼트에 대해 이야기).

1. 인터넷상의 문서. 핵심기술 - Gopher, FTP 등
   인터넷은 지역 자원을 교환하기 위한 글로벌 네트워크입니다.
2. 인터넷 문서. 핵심 기술은 HTML과 HTTP입니다.
   노출된 리소스의 특성은 전송 매체의 특성을 고려합니다.
3. 인터넷 데이터. 핵심기술 - REST, SOAP API, XHR 등
   인터넷 애플리케이션 시대에는 사람만이 자원의 소비자가 되는 것이 아닙니다.
4. 인터넷 데이터. 핵심 기술은 Linked Data 기술입니다.
   두 번째 핵심 기술의 창시자이자 W3C의 이사인 Berners-Lee가 예측한 이 네 번째 단계를 시맨틱 웹(Semantic Web)이라고 합니다. 연결된 데이터 기술은 웹의 데이터를 기계가 읽을 수 있을 뿐만 아니라 "기계가 이해할 수 있게" 만들도록 설계되었습니다.

다음 내용을 통해 독자는 두 번째 단계와 네 번째 단계의 주요 개념 간의 대응 관계를 이해하게 됩니다.

• URL은 URI와 유사합니다.
• HTML의 아날로그는 RDF입니다.
• HTML 하이퍼링크는 RDF 문서의 URI 발생과 유사합니다.

시맨틱 웹은 특정한 자발적이거나 로비적인 추세라기보다는 인터넷의 미래에 대한 체계적인 비전에 가깝지만 후자를 고려할 수 있습니다. 예를 들어, Web 2.0이라고 불리는 것의 중요한 특징은 "사용자 생성 콘텐츠"로 간주됩니다. 특히 W3C 권장 사항에서는 이를 고려해야 합니다.웹 주석 온톨로지"그리고 다음과 같은 사업 고체.

시맨틱 웹은 죽었는가?

거절하는 경우 비현실적인 기대, 의미 웹의 상황은 사회주의가 발전한 시대의 공산주의와 거의 동일합니다 (그리고 일리치의 조건부 명령에 대한 충성이 준수되는지 여부는 모두가 스스로 결정하게하십시오). 검색 엔진 꽤 성공적 웹사이트가 RDFa 및 JSON-LD를 사용하도록 강제하고 자체적으로 아래 설명된 기술(Google Knowledge Graph, Bing Knowledge Graph)과 관련된 기술을 사용합니다.

일반적으로 저자는 무엇이 더 큰 확산을 막고 있는지 말할 수 없지만 개인적인 경험을 바탕으로 말할 수 있습니다. 비록 널리 퍼져 있지는 않지만 SW 공세 상황에서 "즉시" 해결될 수 있는 문제가 있습니다. 결과적으로, 이러한 과제에 직면한 사람들은 솔루션을 제공할 수 있는 사람에 대해 강요할 수단이 없으며, 후자의 독립적인 솔루션 제공은 그들의 비즈니스 모델과 모순됩니다. 그래서 우리는 계속해서 HTML을 구문 분석하고 다양한 API를 서로 연결합니다.

그러나 연결된 데이터 기술은 주류 웹을 넘어 확산되었습니다. 실제로 이 책은 이러한 응용 프로그램에 전념하고 있습니다. 현재 Linked Data 커뮤니티에서는 다음과 같은 추세에 대한 Gartner의 기록(또는 원하는 대로 선언) 덕분에 이러한 기술이 더욱 널리 보급될 것으로 기대하고 있습니다. 지식 그래프 и 데이터 패브릭. 나는 이러한 개념의 "자전거" 구현이 성공할 것이 아니라 아래에서 논의되는 W3C 표준과 관련된 구현이 될 것이라고 믿고 싶습니다.

연결된 데이터

Berners-Lee는 Linked Data를 "올바르게 수행된" 시맨틱 웹, 즉 궁극적인 목표를 달성할 수 있는 일련의 접근 방식과 기술로 정의했습니다. Linked Data의 기본원리 Berners-Lee 점 찍어 다음과 같은.

원칙 1. URI를 사용하여 엔터티 이름을 지정합니다.

URI는 항목에 대한 로컬 문자열 식별자가 아닌 전역 엔터티 식별자입니다. 이후 이 원칙은 Google Knowledge Graph 슬로건 ''에서 가장 잘 표현되었습니다.문자열이 아닌 사물".

원칙 2. 역참조가 가능하도록 HTTP 체계에서 URI를 사용합니다.

URI를 참조함으로써 해당 기표 뒤에 있는 기의를 얻는 것이 가능해야 합니다(연산자 이름과의 유사점은 여기에서 명확합니다).*"C에서); 보다 정확하게는 HTTP 헤더의 값에 따라 이를 나타내는 표현을 얻으려는 것입니다. Accept:. 아마도 AR/VR 시대가 도래하면 리소스 자체를 얻는 것도 가능하겠지만, 현재로서는 SPARQL 쿼리를 실행한 결과인 RDF 문서일 가능성이 높다. DESCRIBE.

원칙 3. 특히 URI를 역참조할 때 W3C 표준(주로 RDF(S) 및 SPARQL)을 사용합니다.

연결된 데이터 기술 스택의 이러한 개별 "계층"은 다음과 같이 알려져 있습니다. 시맨틱 웹 레이어 케이크, 아래에 설명되어 있습니다.

원칙 4. 엔터티를 설명할 때 다른 URI에 대한 참조를 사용합니다.

RDF를 사용하면 자원에 대한 자연어 설명으로 제한할 수 있으며 네 번째 원칙은 이를 수행하지 말 것을 요구합니다. 첫 번째 원칙이 보편적으로 준수되면 리소스를 설명할 때 "외국" 리소스를 포함하여 다른 리소스를 참조하는 것이 가능해지며, 이것이 바로 데이터를 링크라고 부르는 이유입니다. 실제로 RDFS 용어집에 명명된 URI를 사용하는 것은 거의 불가피합니다.

RDF

RDF (Resource Description Framework)은 상호 연관된 엔터티를 설명하는 형식입니다.

삼중항이라고 불리는 "주어-술어-객체" 유형의 진술은 개체와 그 관계에 대해 만들어집니다. 가장 간단한 경우에는 주제, 술어 및 객체가 모두 URI입니다. 동일한 URI는 서로 다른 삼중항(주어, 술어, 목적어)의 서로 다른 위치에 있을 수 있습니다. 따라서 삼중항은 RDF 그래프라는 일종의 그래프를 형성합니다.

주체와 객체는 URI일 뿐만 아니라 소위 URI일 수도 있습니다. 빈 노드, 객체도 가능합니다. 리터럴. 리터럴은 문자열 표현과 유형 표시로 구성된 기본 유형의 인스턴스입니다.

리터럴 작성의 예(Turtle 구문에서 자세한 내용은 아래 참조): "5.0"^^xsd:float и "five"^^xsd:string. 유형이 있는 리터럴 rdf:langString 언어 태그도 장착할 수 있으며 Turtle에서는 다음과 같이 작성됩니다. "five"@en и "пять"@ru.

빈 노드는 전역 식별자가 없는 "익명" 리소스이지만 이에 대해 설명할 수 있습니다. 일종의 존재변수.

따라서 (사실 이것이 RDF의 핵심입니다):

• 제목은 URI이거나 빈 노드입니다.
• 술어는 URI입니다.
• 객체는 URI, 빈 노드 또는 리터럴입니다.

조건자가 빈 노드가 될 수 없는 이유는 무엇입니까?

가능한 이유는 삼중항을 비공식적으로 이해하고 XNUMX차 술어 논리의 언어로 번역하려는 욕구 때문입니다. s p o 같은 것 같은 어디에서 - 술어, и - 상수. 이러한 이해의 흔적은 문서에 있습니다.LBase: 시맨틱 웹의 언어에 대한 의미론"는 W3C 워킹 그룹 노트의 상태입니다. 이러한 이해를 통해 삼중항은 s p []어디에서 [] - 빈 노드는 다음과 같이 번역됩니다. 어디에서 -변수이지만 번역하는 방법 s [] o? W3C 권장 사항 상태가 포함된 문서 "RDF 1.1 의미론”는 또 다른 번역 방법을 제공하지만 여전히 술어가 빈 노드일 가능성을 고려하지 않습니다.

그러나 마누 스포르니 허용 된.

RDF는 추상적인 모델입니다. RDF는 다양한 구문으로 작성(직렬화)될 수 있습니다. RDF/XML, 터틀 (대부분 사람이 읽을 수 있음), JSON-LD, HDT (바이너리).

동일한 RDF는 다양한 방식으로 RDF/XML로 직렬화될 수 있으므로, 예를 들어 XSD를 사용하여 결과 XML의 유효성을 검사하거나 XPath를 사용하여 데이터를 추출하는 것은 의미가 없습니다. 마찬가지로 JSON-LD는 Javascript의 점 및 대괄호 표기법을 사용하여 RDF로 작업하려는 일반적인 Javascript 개발자의 욕구를 충족시키지 못할 것입니다(JSON-LD는 메커니즘을 제공하여 해당 방향으로 이동하지만). 프레이밍).

대부분의 구문은 긴 URI를 단축하는 방법을 제공합니다. 예를 들어, 광고 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> Turtle에서는 대신 쓸 수 있습니다 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 막 rdf:type.

RDFS

RDFS (RDF 스키마) - 기본 모델링 어휘로, 속성과 클래스의 개념을 소개하고 다음과 같은 속성을 소개합니다. rdf:type, rdfs:subClassOf, rdfs:domain и rdfs:range. 예를 들어 RDFS 사전을 사용하면 다음과 같은 유효한 표현식을 작성할 수 있습니다.

rdf:type         rdf:type         rdf:Property .
rdf:Property     rdf:type         rdfs:Class .
rdfs:Class       rdfs:subClassOf  rdfs:Resource .
rdfs:subClassOf  rdfs:domain      rdfs:Class .
rdfs:domain      rdfs:domain      rdf:Property .
rdfs:domain      rdfs:range       rdfs:Class .
rdfs:label       rdfs:range       rdfs:Literal .

RDFS는 설명 및 모델링 어휘이지만 제약 언어는 아닙니다(공식 사양 및 이파리 그러한 사용 가능성). "스키마"라는 단어는 "XML 스키마"라는 표현과 동일한 의미로 이해되어서는 안 됩니다. 예를 들어, :author rdfs:range foaf:Person 그 의미 rdf:type 모든 속성 값 :author - foaf:Person, 그러나 이것이 미리 말해야 함을 의미하지는 않습니다.

스파클

스파클 (SPARQL 프로토콜 및 RDF 쿼리 언어) - RDF 데이터를 쿼리하기 위한 언어입니다. 간단한 경우 SPARQL 쿼리는 쿼리되는 그래프의 세 쌍이 일치하는 샘플 집합입니다. 패턴은 주제, 술어 및 객체 위치에 변수를 포함할 수 있습니다.

쿼리는 샘플에 대체될 때 쿼리된 RDF 그래프의 하위 그래프(XNUMX개 항목의 하위 집합)가 생성될 수 있는 변수 값을 반환합니다. 서로 다른 세 쌍의 샘플에 있는 동일한 이름의 변수는 동일한 값을 가져야 합니다.

예를 들어, 위의 XNUMX개 RDFS 공리 집합이 있는 경우 다음 쿼리는 다음을 반환합니다. rdfs:domain и rdfs:range 값으로 ?s и ?p 각기:

SELECT * WHERE {
 ?s ?p rdfs:Class .
 ?p ?p rdf:Property .
}

SPARQL은 선언적이며 그래프 순회를 설명하는 언어가 아니라는 점은 주목할 가치가 있습니다(그러나 일부 RDF 저장소는 쿼리 실행 계획을 조정하는 방법을 제공합니다). 따라서 최단 경로 찾기와 같은 일부 표준 그래프 문제는 SPARQL에서 해결할 수 없습니다. 속성 경로 (그러나 개별 RDF 저장소는 이러한 문제를 해결하기 위해 특별한 확장 기능을 제공합니다).

SPARQL은 세계의 개방성에 대한 가정을 공유하지 않고 "실패로서의 부정" 접근 방식을 따릅니다. 가능하다 다음과 같은 디자인 FILTER NOT EXISTS {…}. 메커니즘을 사용하여 데이터 배포가 고려됩니다. 연합 쿼리.

SPARQL 액세스 포인트(SPARQL 쿼리를 처리할 수 있는 RDF 저장소)에는 두 번째 단계와 직접적인 유사점이 없습니다(이 단락의 시작 부분 참조). HTML 페이지가 생성된 내용을 기반으로 하지만 외부에서 액세스할 수 있는 데이터베이스에 비유할 수 있습니다. SPARQL 액세스 포인트는 세 번째 단계의 API 액세스 포인트와 더 유사하지만 두 가지 주요 차이점이 있습니다. 첫째, 여러 개의 "원자적" 쿼리를 하나로 결합하는 것이 가능하며(GraphQL의 주요 특징으로 간주됨), 둘째, 이러한 API는 완전히 자체 문서화됩니다(HATEOAS가 달성하려고 시도한 것).

논쟁적인 발언

RDF는 데이터를 웹에 게시하는 방식이므로 RDF 저장소는 문서 DBMS로 간주해야 합니다. 사실, RDF는 트리가 아닌 그래프이기 때문에 그래프 기반인 것으로 나타났습니다. 그것이 전혀 효과가 있다는 것이 놀랍습니다. 빈 노드를 구현하는 똑똑한 사람들이 있을 것이라고 누가 생각이나 했을까요? 코드가 여기 있어요 운동하지 않았다.

또한 RDF 데이터에 대한 액세스를 구성하는 완전한 기능을 갖춘 방법이 적습니다. 예를 들면 다음과 같습니다. 연결된 데이터 조각 (LDF) 및 연계데이터플랫폼 (자민당).

OWL

OWL (웹 온톨로지 언어) - 지식을 표현하기 위한 형식주의, 설명 논리의 구문적 버전 (아래에서는 OWL 2라고 말하는 것이 더 정확합니다. OWL의 첫 번째 버전은 다음을 기반으로 했습니다. ).

OWL의 설명 논리 개념은 클래스에 해당하고, 역할은 속성에 해당하며, 개인은 이전 이름을 유지합니다. 공리는 공리라고도 합니다.

예를 들어, 소위 맨체스터 구문 OWL 표기법의 경우 이미 우리에게 알려진 공리입니다. 다음과 같이 작성됩니다.

Class: Human
Class: Parent
   EquivalentClass: Human and (inverse hasParent) some Human
ObjectProperty: hasParent

OWL을 작성하기 위한 다른 구문은 다음과 같습니다. 함수형 구문, 공식 사양에 사용됨 올빼미/XML. 또한 OWL은 직렬화될 수 있습니다. RDF 구문을 추상화하기 위해 그리고 더 나아가 - 특정 구문 중 하나에서.

OWL은 RDF와 이중 관계를 갖고 있습니다. 한편으로는 RDFS를 확장한 일종의 사전이라고 볼 수도 있다. 반면에 RDF는 단지 직렬화 형식에 불과한 더욱 강력한 형식입니다. 모든 기본 OWL 구성이 단일 RDF 삼중항을 사용하여 작성될 수 있는 것은 아닙니다.

OWL 구성의 어떤 하위 집합을 사용할 수 있는지에 따라 소위 말하는 올빼미 프로필. 표준화되고 가장 유명한 것은 OWL EL, OWL RL 및 OWL QL입니다. 프로파일 선택은 일반적인 문제의 계산 복잡성에 영향을 미칩니다. 다음에 해당하는 완전한 OWL 구성 세트 , OWL DL이라고 합니다. 때때로 그들은 의미론적 및 계산적 제한 없이 RDF 고유의 완전한 자유와 함께 OWL 구성을 사용할 수 있는 OWL Full에 대해서도 이야기합니다. . 예를 들어, 어떤 것은 클래스이자 속성일 수 있습니다. OWL Full은 결정할 수 없습니다.

OWL에서 결과를 부여하는 핵심 원칙은 개방형 세계 가정을 채택하는 것입니다. OWA) 및 고유명 추정 거부(고유명 가정, 하나). 아래에서는 이러한 원칙이 일부 OWL 구성을 이끌고 도입할 수 있는 위치를 살펴보겠습니다.

온톨로지에 다음 조각(맨체스터 구문)이 포함되어 있다고 가정합니다.

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human
   Facts: hasChild Alice, hasChild Bob, hasChild Carol

John이 자녀가 많다는 말을 따라야 합니까? UNA를 거부하면 추론 엔진이 이 질문에 부정적으로 대답하게 됩니다. 왜냐하면 Alice와 Bob이 동일한 사람일 수 있기 때문입니다. 다음이 발생하려면 다음 공리를 추가해야 합니다.

DifferentIndividuals: Alice, Bob, Carol, John

이제 온톨로지 조각은 다음과 같은 형식을 갖습니다(John은 많은 자녀를 갖고 있다고 선언되었지만 그에게는 두 명의 자녀만 있습니다):

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human, manyChildren
   Facts: hasChild Alice, hasChild Bob
DifferentIndividuals: Alice, Bob, Carol, John

이 온톨로지는 일관성이 없습니까(유효하지 않은 데이터의 증거로 해석될 수 있음)? OWA를 수락하면 추론 엔진이 부정적으로 응답하게 됩니다. 즉, "어딘가"(다른 온톨로지)에서는 Carol도 John의 자식이라고 말할 수 있습니다.

이러한 가능성을 배제하기 위해 John에 대한 새로운 사실을 추가해 보겠습니다.

Individual: John
   Facts: hasChild Alice, hasChild Bob, not hasChild Carol

다른 자녀의 출현을 제외하기 위해 "자녀 보유" 속성의 모든 값이 사람이고 그 중 XNUMX명만 있다고 가정해 보겠습니다.

ObjectProperty: hasChild
   Domain: Human
   Сharacteristics: Irreflexive
Class: Human
EquivalentTo: { Alice, Bill, Carol, John }

이제 온톨로지는 모순이 되어 추론 엔진이 이를 보고하는데 실패하지 않을 것입니다. 마지막 공리를 통해 우리는 어떤 의미에서 세상을 "닫았으며" John이 자신의 자녀가 될 가능성이 어떻게 배제되는지 주목합니다.

기업 데이터 연결

연결된 데이터 접근 방식 및 기술 세트는 원래 웹에 데이터를 게시하기 위한 것이었습니다. 내부 기업 환경에서 이를 사용하는 데에는 여러 가지 어려움이 있습니다.

예를 들어, 폐쇄적인 기업 환경에서 OWA 채택과 UNA 거부, 웹의 개방적이고 분산된 특성으로 인한 결정을 기반으로 하는 OWL의 연역적 힘은 너무 약합니다. 그리고 여기서는 다음과 같은 해결책이 가능합니다.

• OWL에 의미 체계를 부여하여 OWA를 포기하고 UNA를 채택하고 해당 출력 엔진을 구현함을 의미합니다. - 이 길을 따라서 오고있다 스타독 RDF 스토리지.
• 규칙 엔진을 위해 OWL의 연역적 능력을 포기합니다. — 스타독이 지원합니다 SWRL; Jena와 GraphDB 제공 자신의 언어 규칙
• OWL의 연역적 기능을 거부하고 모델링을 위해 RDFS에 가까운 하나 또는 다른 하위 집합을 사용합니다. - 이에 대한 자세한 내용은 아래를 참조하세요.

또 다른 문제는 기업 세계가 데이터 품질 문제에 더 큰 초점을 맞추고 연결된 데이터 스택에 데이터 검증 도구가 부족하다는 것입니다. 여기의 출력은 다음과 같습니다.

• 적절한 추론 엔진을 사용할 수 있는 경우 닫힌 세계 의미와 고유 이름을 사용하여 OWL 구성의 유효성을 검사하는 데 다시 사용합니다.
• 사용 SHACL, Semantic Web Layer Cake 레이어 목록을 수정한 후 표준화한 것(단, 규칙 엔진으로도 사용할 수 있음), 또는 ShEx.
• 모든 것이 궁극적으로 SPARQL 쿼리로 수행된다는 점을 이해하고 이를 사용하여 자신만의 간단한 데이터 검증 메커니즘을 만듭니다.

그러나 연역적 기능과 검증 도구를 완전히 거부하더라도 연결된 데이터 스택은 데이터 통합 ​​작업에서 개방형 및 분산형 웹과 유사한 작업에서 경쟁에서 밀려납니다.

일반 기업 정보 시스템은 어떻습니까?

이는 가능하지만, 물론 해당 기술이 해결해야 할 문제가 무엇인지 정확히 알고 있어야 합니다. 여기서는 기존 IT의 관점에서 이 기술 스택이 어떤 모습인지 보여주기 위해 개발 참가자의 일반적인 반응을 설명하겠습니다. 코끼리의 비유가 조금 생각나네요.

• 비즈니스 분석가: RDF는 직접 저장된 논리 모델과 같습니다.
• 시스템 분석가: RDF는 다음과 같다 에브, 많은 인덱스와 편리한 쿼리 언어만 있으면 됩니다.
• 개발자: 음, 이것은 모두 리치 모델과 로우 코드 개념의 정신에 따른 것입니다. 읽다 최근에 이것에 대해.
• 프로젝트 매니저: 응, 똑같아 스택 축소!

실습에 따르면 스택은 MDM(마스터 데이터 관리) 또는 DWH(데이터 웨어하우스) 클래스 시스템을 구축할 때와 같이 데이터의 배포 및 이질성과 관련된 작업에 가장 자주 사용됩니다. 이런 문제는 어느 산업에나 존재합니다.

산업별 애플리케이션 측면에서 Linked Data 기술은 현재 다음 산업에서 가장 널리 사용됩니다.

• 생물의학 기술(그 인기는 해당 분야의 복잡성과 관련이 있는 것으로 보입니다)

현재의

'보일링 포인트'는 최근 '국립의학지식베이스'협회 주관 컨퍼런스를 개최했다.온톨로지를 결합합니다. 이론부터 실제 적용까지".

• 복잡한 제품의 생산 및 운영(대형 기계 공학, 석유 및 가스 생산, 대부분 표준에 대해 이야기함) ISO 15926);

현재의

여기서도 그 이유는 주제 영역의 복잡성 때문입니다. 예를 들어 업스트림 단계에서 석유 및 가스 산업에 대해 이야기하는 경우 간단한 회계에는 일부 CAD 기능이 필요합니다.

2008년에는 Chevron이 주최한 대표적인 설치행사가 열렸습니다. 회의.

결국 ISO 15926은 석유 및 가스 산업에 다소 무거워 보였습니다(아마도 기계 공학에 더 많이 적용됨). 오직 Statoil(Equinor)만이 이 제품에 완전히 매료되었습니다. 노르웨이에서는 전체 제품이 생태계. 다른 사람들은 자신의 일을 하려고 노력하고 있습니다. 예를 들어, 소문에 따르면 국내 에너지부는 다음과 유사한 "연료 및 에너지 단지의 개념적 존재론적 모델"을 만들 계획입니다. 전력 산업을 위해 만들어진.

• 금융 기관(XBRL도 SDMX와 RDF Data Cube 온톨로지의 일종의 하이브리드로 간주될 수 있음)

현재의

연초에 LinkedIn은 TV 시리즈 "Force Majeure"(Goldman Sachs, JPMorgan Chase 및/또는 Morgan Stanley, Wells Fargo)에서 알고 있는 거의 모든 금융 업계 거대 기업의 공석을 저자에게 적극적으로 스팸으로 보냈습니다. SWIFT/Visa/Mastercard, Bank of America, Citigroup, Fed, Deutsche Bank... 아마도 모두가 보낼 수 있는 사람을 찾고 있었을 것입니다. 지식 그래프 컨퍼런스. 꽤 많은 사람들이 발견했습니다. 금융 기관이 모든 것을 가져갔습니다. 첫날 아침.

HeadHunter에서 Sberbank만이 흥미로운 점을 발견했는데, 그것은 "RDF와 유사한 데이터 모델을 갖춘 EAV 스토리지"에 관한 것이었습니다.

아마도 국내와 서구 금융기관의 해당 기술에 대한 사랑 정도의 차이는 후자 활동의 초국적 성격 때문일 것입니다. 분명히 국경을 넘어 통합하려면 질적으로 다른 조직적, 기술적 솔루션이 필요합니다.

• 상용 애플리케이션을 갖춘 질문 답변 시스템(IBM Watson, Apple Siri, Google Knowledge Graph)

현재의

그건 그렇고, Siri의 창시자인 Thomas Gruber는 (IT 의미에서) 온톨로지를 "개념화 사양"으로 정의한 저자입니다. 내 생각에는 이 정의에서 단어를 재배열해도 그 의미가 바뀌지 않으며 아마도 그것이 존재하지 않는다는 것을 나타낼 것입니다.

• 구조화된 데이터 게시(더 큰 정당성은 연결된 오픈 데이터에 기인할 수 있음).

현재의

Linked Data의 열렬한 팬은 소위 GLAM(갤러리, 도서관, 기록 보관소, 박물관)입니다. 의회 도서관이 MARC21의 대체품을 추진하고 있다고만 말하면 충분합니다. 턱받이프레임어느 서지 기술의 미래를 위한 기반을 제공합니다. 물론 RDF를 기반으로 합니다.

Wikidata는 Linked Open Data 분야에서 성공적인 프로젝트의 예로 자주 인용됩니다. 이는 일종의 기계 판독 가능한 Wikipedia 버전으로, DBPedia와 달리 해당 내용은 기사 정보 상자에서 가져오는 방식으로 생성되지 않지만 어느 정도 수동으로 생성되었습니다(그리고 나중에 동일한 정보 상자에 대한 정보 소스가 됩니다).

확인해 보시는 것도 추천드립니다 명부 Stardog 웹사이트의 "고객" 섹션에 있는 Stardog RDF 스토리지 사용자.

Gartner에서는 그럴 수도 있습니다. 2016년 신흥 기술에 대한 하이프 사이클 "기업 분류 및 온톨로지 관리"는 빠르면 10년 내에 "생산성 정체기"에 도달할 것이라는 전망과 함께 실망의 계곡으로 내려가는 중입니다.

기업 데이터 연결

예측, 예측, 예측...

역사적 관심에서 우리가 관심을 갖고 있는 기술에 대한 Gartner의 다양한 예측을 아래 표로 작성했습니다.

년	Технология	신고	직위	정체기까지 수년
2001	시맨틱 웹	신흥 기술	혁신 트리거	5-10
2006	기업 시맨틱 웹	신흥 기술	부풀린 기대의 피크	5-10
2012	시맨틱 웹	빅 데이터	부풀린 기대의 피크	> 10
2015	연결된 데이터	고급 분석 및 데이터 과학	환멸의 여물	5-10
2016	엔터프라이즈 온톨로지 관리	신흥 기술	환멸의 여물	> 10
2018	지식 그래프	신흥 기술	혁신 트리거	5-10

그러나 이미 "하이프 사이클..." 2018 또 다른 상승 추세가 나타났습니다. 바로 지식 그래프입니다. 일종의 환생이 일어났습니다. 사용자의 관심과 개발자의 노력이 전환된 것으로 밝혀진 그래프 DBMS는 전자의 요청과 후자의 습관의 영향을 받아 윤곽과 위치를 잡기 시작했습니다. 이전 경쟁사 중.

이제 거의 모든 그래프 DBMS는 기업의 "지식 그래프"("연결된 데이터"는 때때로 "연결된 데이터"로 대체됨)를 구축하는 데 적합한 플랫폼이라고 선언하지만 그러한 주장은 얼마나 정당합니까?

그래프 데이터베이스는 여전히 의미론적이며, 그래프 DBMS의 데이터는 여전히 동일한 데이터 사일로입니다. URI 대신 문자열 식별자를 사용하면 두 개의 그래프 DBMS를 통합하는 작업이 여전히 통합 작업이 되는 반면, 두 개의 RDF 저장소를 통합하는 것은 단순히 두 개의 RDF 그래프를 병합하는 일로 귀결되는 경우가 많습니다. 의미성의 또 다른 측면은 LPG 그래프 모델의 비반사성인데, 이는 동일한 플랫폼을 사용하여 메타데이터를 관리하기 어렵게 만듭니다.

마지막으로 그래프 DBMS에는 추론 엔진이나 규칙 엔진이 없습니다. 이러한 엔진의 결과는 복잡한 쿼리를 통해 재현할 수 있지만 이는 SQL에서도 가능합니다.

그러나 선도적인 RDF 스토리지 시스템은 LPG 모델을 지원하는 데 어려움이 없습니다. 가장 견고한 접근 방식은 Blazegraph에서 한때 제안된 RDF와 LPG를 결합한 RDF* 모델로 간주됩니다.

더

Habré의 이전 기사에서 LPG 모델에 대한 RDF 스토리지 지원에 대해 자세히 알아볼 수 있습니다. "지금 RDF 스토리지에 무슨 일이 일어나고 있나요?". 언젠가 Knowledge Graph와 Data Fabric에 대한 별도의 기사가 작성되기를 바랍니다. 이해하기 쉬운 마지막 섹션은 급하게 작성되었지만 XNUMX개월이 지난 후에도 이러한 개념으로는 모든 것이 훨씬 명확하지 않습니다.

문학

1. Halpin, H., Monnin, A. (eds.) (2014). 철학적 공학: 웹 철학을 향하여
2. Allemang, D., Hendler, J. (2011) 실무 존재론자를 위한 시맨틱 웹 (2판)
3. Staab, S., Studer, R. (eds.) (2009) 온톨로지 핸드북 (2판)
4. 우드, D. (ed.). (2011) 기업 데이터 연결
5. Keet, M. (2018) 온톨로지 엔지니어링 소개

출처 : habr.com