NLP and others
07 November 2021
Knowledge Graph (KG)를 구축하려면 다음과 같은 것들을 고려하여 미리 디자인을 구상하는 것이 좋다.
또한 어떤 source를 활용하여 구축할 지도 생각해보아야 한다. 이미 만들어져 있는 structured data를 활용할 것인지, 가공되지 않은 텍스트를 사용할 것인지, 아니면 사람이 일일히 작업할 것인지 등. KG 구축의 목적을 생각해보면 된다. 만약 웹상에서 정보를 제공하기 위함이라면 아주 높은 정확도를 맞출 필요가 없음으로 사람이 직접 작업하기 위한 비용이 드는 것은 합리적이지 않다. 하지만 기업 내에서 사용될 정교한 데이터라면 비용이 더 들더라도 사람이 작업하는 것이 합리적일 것이다.
이전 포스트에서 RDF data model과 property graph model에 대해 알아보았다. 이들을 구축한다면 각각 어떤 특징과 장단점이 있을까?
먼저 두 모델 모두 reification을 사용하여 triple로 직접 모델할 수 없는 경우를 대처한다. RDF model은 IRI를 필요로하는 반면 property model에서는 필수가 아니다. 반면 property model에서는 하나의 값(value)이 property나 node로 표현되어야 하는지 고려해야 할 것이다.
이렇게 두 모델의 특징이 다른 만큼 구축하는 방법과 필요로 하는 것 또한 다를 것이다. 좀 더 자세히 알아보자.
WWW의 RDF 데이터에 대한 KG 구축 지침은 다음과 같은 linked data principles로 알려져 있다.
가령, WWW에 나의 KG를 퍼블리시한다고 생각해보자. 그러기 위해선 다양한 아이템들(즉, node들)을 먼저 정해야 한다. KG에서 그 아이템들은 properties와 relations로 표현될 것이다. WWW에서 이러한 아이템들은 resource라고 불리는데, 크게 information resource와 non-information resource로 분류된다. 간단히 설명하자면 전자는 document, image, media file과 같은 일정한 정보를 가지고 있는 아이템이다. 후자는 사람(이름), 장소(이름), 제품(이름)과 같은 정보를 포함하지 않은 아이템이다. 우리의 KG는 후자인 non-information resource를 가지고 구축해 나가게 된다.
한개의 웹페이지로 한개의 아이템을 나타낸다면, KG를 구축하는 궁극적인 목표인 정보 조회가 쉬워야 한다. 하여 URI를 쉬우면서도 분명하게 정의해야한다. 바로 이 때문에 URI가 곧 아이템을 나타내도록 아이템의 이름을 사용하는 것이 유리하다.
URI가 정해졌으면 사람들은 이 URI를 통해 해당 페이지를 열어 정보를 조회할 것이다. 그렇다면 해당 페이지에 포함된 정보 또한 잘 구성되어 있어야 양질의 정보를 제공할 수 있다. 다행히도 Schema.Org와 같은 오픈소스 데이터를 이용하여 우리의 아이템을 RDF와 SPARQL로 구조적으로 나타낼 수 있다. 예시를 보자.
@prefix uk_cabinet: http://reference.data.gov.uk/id/department/
uk_cabinet:co rdf:type org:Organization
uk_cabinet:co skos:prefLabel “Cabinet Office”
uk_cabinet:co org:hasUnit uk_cabinet:cabinet-office-communications
uk_cabinet:cabinet-office-communications rdf:type org:OrganizationUnit
uk_cabinet:cabinet-office-communications skos:prefLabel “Cabinet Office Communications”
uk_cabinet:cabinet-office-communications org:hasPost uk_cabinet:post_246
uk_cabinet:post_246 skos:prefLabel “Deputy Director, Deputy Prime Minister’s Spokesperson”
위 예시에서는 UK Cabinet office의 조직 구조의 일부가 설명된다. 각각의 triple은 웹상에 존재하는 vocabulary들을 이용하여 표현이 되었는데, 사실 내가 RDF 데이터셋을 만드는 데 있어 필요한 모든 vocabulary가 존재하는 것은 아니다. 새로운 vocabulary를 만들어야 하는 상황에서 고려해야 하는 많은 부분이 있는데 이 포스트에서 자세한 것은 다루지 않는다.
그렇다면 마지막으로 다른 URI 링크를 포함시키기 위해 고려해야 할 것들을 알아보자.
여기서 말하는 링크는 크게 세가지 종류가 있다.
첫번째로 relationship links는 이름과 같이 다른 연관된 data source를 가리킨다. 가령 누군가가 사는 지역, 가족 관계, 다니는 회사 등이 있을 수 있다. 아래 triple을 살펴보면 한 사람의 지역 정보가 다른 데이터셋의 URI를 이용하여 링크되어있다.
@prefix big: http://biglynx.co.uk/people/
@prefix dbpedia: http://dbpedia.org/resource/
big:dave-smith foaf:based_near dbpedia:Birmingham
다음으로 identity link는 다른 data source에 존재하는 같은 대상을 가리킨다.
다시 말하면 다른 데이터셋에 존재하는 같은 아이템을 표현하는 source를 인용하기 위해 사용되는 링크인데,
일반적인 사용법은 http://www.w3.org/2002/07/owl#sameAs link type으로 서로 다른 두 URI가 가리키는 것이 같은 resource임을 명시하는 것이다.
가령, Big Lynx라는 사람의 웹페이지에 Dave Smith라는 사람의 정보가 있고, Dave Smith가 이것을 이용하여 자신의 개인 웹페이지를 구축하고 싶다고 하자.
실질적으로 두 웹페이지가 가리키는 대상은 모두 Dave Smith로 같은 아이템이므로, identity link를 이용할 수 있는 것이다.
이것에 대한 triple은 다음과 같이 나타낼 수 있다.
@prefix ds: http://www.dave-smith.eg.uk
@prefix owl: http://www.w3.org/2002/07/owl
@prefix big: http://biglynx.co.uk/people/
ds:me owl:sameAs big:dave-smith
마지막으로 vocabulary link는 이름과 같이 해당 아이템이 표현되어 있는 기존의 vocabulary를 인용하는 것이다. 예시는 다음과 같다.
@prefix dbpedia: http://dbpedia.org/ontology/
big:sme#SmallMediumEnterprise rdfs:subClassOf dbpedia:Company
이렇게 RDF graph를 구축하기 위해 필요한 것들을 알아보았다. 다른 특성을 지닌 property graph는 어떨까?
Property graph를 디자인하려면 node 및 node label과 property, 그리고 edge 및edge property를 모두 선정해야 한다. 자세히는 어떠한 정보를 property나 label로 나타낼 것인지 아예 동떨어진 object로 나타낼 것인지를 정해야 하며, relation property는 어떠한 경우에 사용할 것이고 복잡한 관계(arity relationship)는 어떻게 할 것인지를 모두 고려해야 한다.
Property graph model에서는 각각의 node가 곧 entity가 된다. 만약 사람의 정보를 표현하고 싶다면 각각의 사람이 한개의 node가 되고 Person이라는 label을 지니게 된다.
node label, node property, edge를 선정하려면 고려해야 할 것들은 다음과 같다.
한 사람의 성별을 나타낸다고 생각해보자. 다음과 같은 세가지 선택사항이 있다.
여기서 유의할 점이 있다. 그것은 property graph model에 있는 모든 label은 node들을 각각의 그룹으로 분리할 수 있다는 점이다. 즉 같은 label을 가진 모든 node들은 한 그룹에 속하며, 이를 이용해 graph 전체가 아닌 각각의 그룹에 대한 query로 작업할 수 있다. 쉽게 말하면 label은 즉 class와 같다. 이것을 고려하면 언제 label을 새로 만들지에 대해 생각해볼 수 있겠다.
가령, Male 과 Female class를 따로 만들 것인가? 아니면 “gender”라는 node property와 “male” , “female” value를 사용할 것인가? 이 둘이 나타내는 정보는 같지만 상황에 따라 그래프의 효율성을 좌지우지 할 수 있다.
좀 더 자세히 알아보자!
위에서 언급한 상황에서 고려해야할 것은 두가지가 있다.
같은 예시를 가지고 얘기해보자면 만약 사람의 성별이 시간이 지남에 따라 바뀔 수 있다면 더 나은 선택은 Gender object를 따로 정의하여 has_gender relation으로 Person object에 잇는 것이다. 우리가 생각해볼 점은 Gender 라는 node를 따로 만든다는 것이 수많은 edges를 만들게 한다는 점이다. 수많은 edges를 만들고 유지해야할 정도로 많은 사람들의 성별이 시간에 따라 바뀔까? 이러한 경우에는 즉, 새로운 node를 만드는 것은 비효율적이다. 만약 시간에 따라 바뀔 수 있는 property를 지닌 node가 어느정도 된다면 타협점을 찾아볼 수도 있는데, 그것은 바로 기본적으로 node property value로 성별을 나타내되, 일부의 사람만 따로 Gender node 을 이용하여 성별을 나타내는 것이다.
query performance의 관점에서 확인해보자. 영화의 장르를 모델링할 때, 다음 두가지 방식 중 선택하려고 한다..
(1)
MATCH (m1:Movie), (m2:Movie)
WHERE any(x IN m1.genre WHERE x IN m2.genre)
AND m1 <> m2
RETURN m1, m2
(2)
MATCH (m1:Movie)-[:has_genre]->(g:Genre),
(m2:Movie)-[:has_genre]->(g)
WHERE m1 <> m2
RETURN m1, m2
첫번째 경우는 node property로 “Action” 이나 “SciFi”와 같은 장르 이름을 node에 바로 연관시킬 수 있다. 두번째 경우 새로운 node를 만들어 유지해야 할 label이 많아지는 반면, 좀 더 직관적인 graph pattern을 만들 수 있고 그에 따라 relation을 인덱스 할 때 (일반적으로) 더욱 빠른 runtime performance를 보여줄 것이다. 두 방법 중 무조건 더 나은 방식은 없으며, 이러한 사항들을 고려해서 상황에 따라 알맞는 방식을 선택하는 것이 중요하다.
Reference: https://web.stanford.edu/class/cs520/