Семаль вэб ба холбосон өгөгдөл. Залруулга, нэмэлтүүд

Саяхан хэвлэгдсэн энэхүү номноос нэг хэсгийг олон нийтэд толилуулъя.

Аж ахуйн нэгжийн онтологийн загварчлал: арга, технологи [Текст]: монографи / [С. В.Горшков, С.С.Кралин, О.И.Муштак болон бусад; Гүйцэтгэх редактор С.В.Горшков]. - Екатеринбург: Уралын их сургуулийн хэвлэлийн газар, 2019. - 234 х.: өвчтэй, хүснэгт; 20 см - Зохиогч. арын толгойн хэсэгт заасан. -тай. - Ном зүй ch-ийн төгсгөлд. — ISBN 978-5-7996-2580-1: 200 хувь.

Энэ хэсгийг Хабре дээр нийтлэх зорилго нь дөрвөн зүйл юм.

  • Хүндэтгэгчийн үйлчлүүлэгч биш бол хэн ч энэ номыг гартаа атгах нь юу л бол Серж индекс; Энэ нь мэдээж худалдаанд гарахгүй.
  • Текстэнд залруулга (доор онцлон тэмдэглээгүй) хийгдсэн бөгөөд хэвлэсэн монографийн форматтай тийм ч нийцэхгүй нэмэлтүүд хийгдсэн: сэдэвчилсэн тэмдэглэл (спойлерын доор) болон гипер холбоосууд.
  • Би хүсч байна асуулт, санал цуглуулах, энэ текстийг бусад хэвлэлд шинэчилсэн хэлбэрээр оруулахдаа тэдгээрийг харгалзан үзэхийн тулд.
  • Семаль вэб болон холбосон өгөгдлийг дагаж мөрддөг олон хүмүүс өөрсдийн хүрээлэл маш нарийссан гэдэгт итгэдэг бөгөөд гол нь олон нийтэд Семаль вэб болон холбосон өгөгдлийг дагаж мөрддөг байх нь ямар агуу болохыг зөв тайлбарлаагүй байгаа юм. Хэсгийн зохиогч хэдийгээр энэ тойрогт харьяалагддаг ч ийм үзэл бодолтой байдаггүй ч өөрийгөө дахин оролдлого хийх үүрэгтэй гэж үздэг.

Тэгэхээр

Семантик вэб

Интернетийн хувьслыг дараах байдлаар илэрхийлж болно (эсвэл доор заасан дарааллаар үүссэн сегментүүдийн талаар ярих).

  1. Интернет дэх баримт бичиг. Гол технологиуд - Gopher, FTP гэх мэт.
    Интернет бол орон нутгийн нөөцийг солилцох дэлхийн сүлжээ юм.
  2. Интернетийн баримт бичиг. Гол технологи нь HTML болон HTTP юм.
    Ил гарсан нөөцийн шинж чанар нь тэдгээрийн дамжуулах орчны шинж чанарыг харгалзан үздэг.
  3. Интернет өгөгдөл. Гол технологиуд - REST ба SOAP API, XHR гэх мэт.
    Интернетийн хэрэглээний эрин үе бол зөвхөн хүмүүс нөөцийн хэрэглэгч болж хувирдаггүй.
  4. Интернет өгөгдөл. Гол технологиуд нь Linked Data технологи юм.
    Хоёрдахь технологийн гол технологийг бүтээгч, W3C-ийн захирал Бернерс-Лигийн таамагласан энэ дөрөв дэх үе шатыг семантик вэб гэж нэрлэдэг; Холбогдсон өгөгдлийн технологи нь вэб дээрх өгөгдлийг зөвхөн машинд унших боломжтой төдийгүй "машинаар ойлгомжтой" болгох зорилготой юм.

Дараахь зүйлээс уншигч хоёр, дөрөв дэх үе шатны гол ойлголтуудын хоорондын уялдаа холбоог ойлгох болно.

  • URL нь URI-тай төстэй,
  • HTML-ийн аналог нь RDF,
  • HTML гипер холбоосууд нь RDF баримт бичигт URI тохиолдлуудтай төстэй.

Семаль вэб нь тодорхой аяндаа эсвэл лоббиддог чиг хандлагаас илүүтэй интернетийн ирээдүйн талаар системчилсэн төсөөлөл юм, гэхдээ эдгээрийг харгалзан үзэж болно. Жишээлбэл, Вэб 2.0 гэж нэрлэгддэг нэг чухал шинж чанарыг "хэрэглэгчийн үүсгэсэн контент" гэж үздэг. Ялангуяа W3C зөвлөмжид үүнийг анхааралдаа авахыг уриалж байна "Вэб аннотацийн онтологи"мөн ийм ажил Хатуу.

Семаль вэб үхсэн үү?

Хэрэв та татгалзвал бодит бус хүлээлт, семантик вэбийн нөхцөл байдал нь хөгжингүй социализмын үеийн коммунизмтай ойролцоогоор ижил байна (мөн Ильичийн болзолт зарлигт үнэнч байх эсэхийг хүн бүр өөрөө шийднэ). Хайлтын системүүд нэлээд амжилттай вэбсайтуудыг RDFa болон JSON-LD ашиглахыг албаддаг бөгөөд өөрсдөө доор тайлбарласантай холбоотой технологиудыг ашигладаг (Google Knowledge Graph, Bing Knowledge Graph).

Ерөнхийдөө зохиолч илүү их тархахаас юу сэргийлж байгааг хэлж чадахгүй ч хувийн туршлага дээрээ үндэслэн ярьж болно. SW-ийн довтолгооны нөхцөлд "хайрцагнаас гадуур" шийдэж болох асуудлууд байдаг, гэхдээ тэдгээр нь тийм ч өргөн тархаагүй байдаг. Үүний үр дүнд эдгээр даалгавартай тулгарсан хүмүүст шийдэл гаргаж чадах хүмүүсийн эсрэг албадлагын арга байхгүй, харин бие даасан шийдлийн заалт нь тэдний бизнесийн загвартай зөрчилдөж байна. Тиймээс бид HTML-г задлан шинжилж, өөр өөр API-г нааж, өөр хоорондоо илүү новшийн.

Гэсэн хэдий ч, Linked Data технологи нь нийтлэг вэбээс хальж тархсан; Уг ном нь эдгээр програмуудад зориулагдсан болно. Одоогийн байдлаар Linked Data нийгэмлэг нь Gartner гэх мэт чиг хандлагыг бүртгэсний (эсвэл таны хүссэнээр тунхагласан) ачаар эдгээр технологиуд илүү өргөн тархах болно гэж найдаж байна. Мэдлэгийн график и Өгөгдлийн даавуу. Эдгээр үзэл баримтлалын "унадаг дугуй" биш, харин доор авч үзсэн W3C стандарттай холбоотой зүйлүүд амжилтанд хүрнэ гэдэгт би итгэхийг хүсч байна.

Холбоотой өгөгдөл

Бернерс-Ли Холбогдсон өгөгдлийг "зөв хийгдсэн" семантик вэб гэж тодорхойлсон бөгөөд энэ нь эцсийн зорилгодоо хүрэх боломжийг олгодог арга барил, технологийн багц юм. Холбогдсон өгөгдлийн үндсэн зарчмууд Бернерс-Ли онцолсон дараах.

1-р зарчим. Байгууллагуудыг нэрлэхийн тулд URI ашиглах.

URI нь оруулгуудын локал стринг танигчаас ялгаатай нь дэлхийн аж ахуйн нэгжийн танигч юм. Дараа нь энэ зарчмыг "Google Knowledge Graph" уриа дээр хамгийн сайн илэрхийлсэн.утас биш юмс".

2-р зарчим. HTTP схемд URI-г ашигласнаар тэдгээрт хамааралгүй болно.

URI-д хандсанаар тухайн тэмдэглэгчийн ард байгаа тэмдэглэгээг олж авах боломжтой байх ёстой (операторын нэрний зүйрлэл энд тодорхой байна).*"C дээр); илүү нарийвчлалтай, HTTP толгойн утгаас хамааран энэ нь ямар нэг дүрслэлийг авах Accept:. Магадгүй AR/VR эрин үе гарч ирснээр нөөцийг өөрөө олж авах боломжтой болох боловч одоогоор энэ нь SPARQL хайлтыг гүйцэтгэсэн RDF баримт бичиг байх магадлалтай. DESCRIBE.

3-р зарчим. W3C стандартыг ялангуяа RDF(S) болон SPARQL-ийг ашиглах, ялангуяа URI-н лавлагааг хасах үед.

Холбогдсон өгөгдлийн технологийн стекийн эдгээр бие даасан "давхаргууд" гэж нэрлэдэг Семантик вэб давхаргын бялуу, доор тайлбарлах болно.

4-р зарчим. Байгууллагуудыг тайлбарлахдаа бусад URI-ийн лавлагааг ашиглах.

RDF нь нөөцийг байгалийн хэлээр аман тайлбараар хязгаарлах боломжийг олгодог бөгөөд дөрөв дэх зарчим нь үүнийг хийхгүй байхыг шаарддаг. Хэрэв эхний зарчмыг бүх нийтээр дагаж мөрдвөл эх сурвалжийг тайлбарлахдаа бусад, тэр дундаа "гадны" гэх мэт мэдээллийг ашиглах боломжтой болдог тул өгөгдлийг холбосон гэж нэрлэдэг. Үнэн хэрэгтээ RDFS үгсийн санд нэрлэгдсэн URI-г ашиглах нь бараг зайлшгүй юм.

RDF

RDF (Нөөцийн тодорхойлолтын хүрээ) нь харилцан хамааралтай аж ахуйн нэгжүүдийг дүрслэх формализм юм.

Гурвалсан гэж нэрлэгддэг "субъект-предикат-объект" төрлийн мэдэгдлүүд нь аж ахуйн нэгжүүд болон тэдгээрийн харилцааны талаар хийгдсэн байдаг. Хамгийн энгийн тохиолдолд субьект, предикат, объект нь бүгд URI юм. Нэг URI нь өөр өөр гурвалсан байрлалд байж болно: субьект, предикат, объект байх; Ийнхүү гурвалсанууд нь RDF график гэж нэрлэгддэг нэг төрлийн график үүсгэдэг.

Субъектууд болон объектууд нь зөвхөн URI биш, бас гэж нэрлэгддэг байж болно хоосон зангилаа, мөн объектууд бас байж болно үг хэллэг. Литерал гэдэг нь мөрийн дүрслэл болон төрлийн заалтаас бүрдэх энгийн төрлүүдийн жишээ юм.

Бичиг үсэг бичих жишээнүүд (Мэлхий синтакс дээр доороос дэлгэрэнгүй авч үзнэ үү): "5.0"^^xsd:float и "five"^^xsd:string. Төрөлтэй үсэг rdf:langString Мөн хэлний шошготой байж болно; яст мэлхий дээр дараах байдлаар бичигдсэн байдаг. "five"@en и "пять"@ru.

Хоосон зангилаанууд нь дэлхийн танигчгүй "нэргүй" нөөц бөгөөд тэдгээрийн талаар мэдэгдэл хийх боломжтой; оршин тогтнох хувьсагчдын төрөл.

Тиймээс (энэ нь үнэндээ RDF-ийн бүх санаа юм):

  • сэдэв нь URI эсвэл хоосон зангилаа,
  • предикат нь URI,
  • объект нь URI, хоосон зангилаа эсвэл литерал юм.

Яагаад предикатууд хоосон зангилаа байж болохгүй гэж?

Болзошгүй шалтгаан нь гурвалсан утгыг албан бусаар ойлгож, нэгдүгээр зэрэглэлийн предикатын логик хэл рүү орчуулах хүсэл юм. 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#> Мэлхий дээр дараа нь оронд нь бичихийг зөвшөөрөх болно <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> зүгээр л rdf:type.

RDFS

RDFS (RDF Schema) - загварчлалын үндсэн толь бичиг нь өмч, анги, шинж чанаруудын тухай ойлголтуудыг танилцуулдаг. 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

SPARQL (SPARQL Protocol and RDF Query Language) - RDF-ийн өгөгдөлд асуулга хийх хэл. Энгийн тохиолдолд, SPARQL асуулга нь асууж буй графикийн гурвалсан хэсгүүдтэй таарч тохирох түүврийн багц юм. Загвар нь субьект, предикат, объектын байрлал дахь хувьсагчдыг агуулж болно.

Асуулга нь ийм хувьсагчийн утгуудыг буцаана, түүвэрт орлуулснаар асуусан RDF графикийн дэд график (түүний гурвалсан дэд хэсэг) гарч ирнэ. Гурвалсан хүүхдийн өөр өөр түүврийн ижил нэртэй хувьсагчид ижил утгатай байх ёстой.

Жишээлбэл, дээрх долоон 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) болон Холбоотой мэдээллийн платформ (LDP).

OWL

OWL (Вэб онтологийн хэл) - мэдлэгийг илэрхийлэх формализм, тайлбарын логикийн синтакс хувилбар Семаль вэб ба холбосон өгөгдөл. Залруулга, нэмэлтүүд (Доор талд OWL 2 гэж хэлэх нь илүү зөв бөгөөд OWL-ийн анхны хувилбар дээр үндэслэсэн болно Семаль вэб ба холбосон өгөгдөл. Залруулга, нэмэлтүүд).

OWL-д тайлбарлах логикийн тухай ойлголтууд нь ангиудад, үүрэг нь шинж чанаруудтай тохирч, хувь хүмүүс өмнөх нэрээ хадгалдаг. Аксиомуудыг аксиом гэж бас нэрлэдэг.

Жишээлбэл, гэж нэрлэгддэг зүйлд Манчестерийн синтакс OWL тэмдэглэгээний хувьд бидний мэддэг аксиом Семаль вэб ба холбосон өгөгдөл. Залруулга, нэмэлтүүд дараах байдлаар бичигдэх болно.

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

гэх мэт OWL бичих өөр синтаксууд байдаг функциональ синтакс, албан ёсны тодорхойлолтод ашигласан, мөн OWL/XML. Нэмж дурдахад OWL-ийг цуваа болгож болно RDF синтаксийг хийсвэрлэх ба цаашлаад - тодорхой синтаксуудын аль нэгэнд.

OWL нь RDF-тэй хос харилцаатай байдаг. Энэ нь нэг талаас RDFS-ийг өргөтгөсөн нэг төрлийн толь бичиг гэж үзэж болно. Нөгөө талаас, энэ нь RDF нь зүгээр л цуваа формат болох илүү хүчирхэг формализм юм. Бүх энгийн OWL бүтцийг нэг RDF триплет ашиглан бичиж болохгүй.

OWL-ийн аль дэд бүтцийг ашиглахыг зөвшөөрч байгаагаас хамааран тэдгээр нь гэж нэрлэгддэг зүйлийн талаар ярьдаг OWL профайл. Стандартчилагдсан бөгөөд хамгийн алдартай нь OWL EL, OWL RL, OWL QL юм. Профайлын сонголт нь ердийн асуудлын тооцооллын нарийн төвөгтэй байдалд нөлөөлдөг. Харгалзах OWL бүтцийн иж бүрэн багц Семаль вэб ба холбосон өгөгдөл. Залруулга, нэмэлтүүд, OWL DL гэж нэрлэдэг. Заримдаа тэд OWL Full-ийн тухай ярьдаг бөгөөд OWL бүтцийг RDF-д хамаарах бүрэн эрх чөлөөгөөр, семантик болон тооцооллын хязгаарлалтгүйгээр ашиглахыг зөвшөөрдөг. Семаль вэб ба холбосон өгөгдөл. Залруулга, нэмэлтүүд. Жишээлбэл, ямар нэг зүйл анги, өмч хоёулаа байж болно. OWL Full гэдгийг шийдэх боломжгүй.

OWL-д үр дагаврыг хавсаргах гол зарчим бол нээлттэй ертөнцийн таамаглалыг батлах явдал юм. О.В.А.) болон өвөрмөц нэрийн таамаглалыг үгүйсгэх (өвөрмөц нэрний таамаглал, НЭГ). Доор бид эдгээр зарчмууд нь хаашаа чиглүүлж, зарим OWL бүтцийг танилцуулж болохыг олж харах болно.

Онтологи нь дараах фрагментийг агуулна (Манчестер синтакс дээр):

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

Энэ нь Жон олон хүүхэдтэй гэж хэлсэн зүйлээс гарах уу? Алис, Боб хоёр ижил хүн байж магадгүй тул UNA-г үгүйсгэх нь дүгнэлтийн хөдөлгүүрийг энэ асуултад сөрөг хариулах болно. Дараахь үйлдлийг хийхийн тулд дараахь аксиомыг нэмэх шаардлагатай.

DifferentIndividuals: Alice, Bob, Carol, 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-г хүлээн авснаар дүгнэлтийн хөдөлгүүр сөрөг хариу үйлдэл үзүүлэх болно: өөр "хаа нэгтээ" (өөр онтологи дээр) Кэрол бас Жонны хүүхэд гэж хэлж болно.

Үүнийг үгүйсгэхийн тулд Жонны тухай шинэ баримтыг нэмж хэлье.

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

Бусад хүүхдүүдийн дүр төрхийг үгүйсгэхийн тулд "хүүхэд төрүүлэх" өмч хөрөнгийн бүх үнэт зүйл бол зөвхөн дөрөв нь байдаг хүмүүс гэж хэлье.

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

Одоо онтологи нь зөрчилдөөнтэй болох бөгөөд үүнийг дүгнэлтийн хөдөлгүүр мэдээлэхгүй байх болно. Сүүлчийн аксиомоор бид дэлхийг "хаалттай" болгож, Жон өөрийн хүүхэд байх магадлалыг хэрхэн үгүйсгэж байгааг анзаараарай.

Байгууллагын өгөгдлийг холбох

Холбогдсон өгөгдлийн арга барил, технологийн багц нь анх вэб дээр өгөгдлийг нийтлэх зорилготой байсан. Тэднийг байгууллагын дотоод орчинд ашиглах нь хэд хэдэн бэрхшээлтэй тулгардаг.

Жишээлбэл, хаалттай корпорацийн орчинд OWA-г батлах, UNA-аас татгалзах, вэбийн нээлттэй, тархсан шинж чанараас шалтгаалан шийдвэр гаргахад үндэслэсэн OWL-ийн дедуктив хүч хэтэрхий сул байна. Мөн энд дараах шийдлүүдийг хийх боломжтой.

  • OWL-ийг семантикаар хангах нь OWA-г орхиж, UNA-г батлах, холбогдох гаралтын хөдөлгүүрийг хэрэгжүүлэх гэсэн үг юм. - Энэ замаар явдаг Stardog RDF хадгалах сан.
  • OWL-ийн дедуктив чадвараас татгалзаж, дүрмийн хөдөлгүүрийг ашиглах. - Stardog дэмждэг SWRL; Жена болон GraphDB санал болгож байна өөрийн хэлүүд дүрэм
  • OWL-ийн дедуктив чадвараас татгалзах, загварчлалын хувьд RDFS-тэй ойролцоо нэг эсвэл өөр дэд бүлгийг ашиглах. - Энэ талаар доороос үзнэ үү.

Өөр нэг асуудал бол корпорацийн ертөнц өгөгдлийн чанарын асуудалд илүү их анхаарал хандуулж болох бөгөөд Холбогдсон өгөгдлийн стек дэх өгөгдлийг баталгаажуулах хэрэгсэл дутагдалтай байгаа явдал юм. Эндээс гарсан үр дүн нь дараах байдалтай байна.

  • Дахин хэлэхэд, тохирох дүгнэлтийн хөдөлгүүр байгаа бол хаалттай ертөнцийн семантик, өвөрмөц нэртэй OWL бүтцийг баталгаажуулахад ашиглаарай.
  • Ашиглах SHACL, семантик вэб давхаргын бялуу давхаргын жагсаалтыг зассаны дараа стандартчилагдсан (гэхдээ үүнийг дүрмийн хөдөлгүүр болгон ашиглаж болно), эсвэл ShEx.
  • Эцсийн эцэст бүх зүйл SPARQL асуулгын тусламжтайгаар хийгддэг гэдгийг ойлгож, тэдгээрийг ашиглан өөрийн энгийн өгөгдөл баталгаажуулах механизмыг бий болго.

Гэсэн хэдий ч дедуктив чадвар болон баталгаажуулалтын хэрэгслээс бүрмөсөн татгалзсан ч холбосон өгөгдлийн стекийг ландшафтын хувьд нээлттэй, түгээсэн вэбтэй ижил төстэй даалгаврууд - өгөгдлийг нэгтгэх ажлуудад өрсөлдөөнөөс гаргадаг.

Байгууллагын байнгын мэдээллийн системийн талаар юу хэлэх вэ?

Энэ нь боломжтой, гэхдээ та холбогдох технологи нь яг ямар асуудлыг шийдэх ёстойг мэдэж байх ёстой. Энэхүү технологийн стек нь ердийн мэдээллийн технологийн үүднээс хэрхэн харагддагийг харуулахын тулд хөгжүүлэлтийн оролцогчдын ердийн хариу үйлдлийг би энд тайлбарлах болно. Зааны тухай сургаалт зүйрлэлийг бага зэрэг санагдуулдаг:

  • Бизнесийн шинжээч: RDF нь шууд хадгалагдсан логик загвартай адил зүйл юм.
  • Системийн шинжээч: RDF ийм байна EAV, зөвхөн олон тооны индексүүд болон тохиромжтой хайлтын хэлээр.
  • хөгжүүлэгч: за, энэ бүхэн баялаг загвар, бага код гэсэн ойлголтын сүнсэнд байгаа юм. уншиж байсан саяхан энэ талаар.
  • Төслийн менежер: тиймээ адилхан стекийг нурааж байна!

Дадлагаас харахад стекийг ихэвчлэн мэдээллийн хуваарилалт, нэг төрлийн бус байдалтай холбоотой ажлуудад, жишээлбэл, MDM (Master Data Management) эсвэл DWH (Data Warehouse) ангиллын системийг бий болгоход ашигладаг. Ийм асуудал аль ч салбарт байдаг.

Салбарын тусгай хэрэглээний хувьд Linked Data технологи нь одоогоор дараах салбаруудад хамгийн түгээмэл байдаг.

  • биоанагаахын технологи (тэдгээрийн түгээмэл байдал нь домэйны нарийн төвөгтэй байдалтай холбоотой юм шиг санагддаг);

Одоогийн

Саяхан “Буцлах цэг”-т “Үндэсний анагаах ухааны мэдлэгийн сан” нийгэмлэгээс зохион байгуулсан “Эрдэм шинжилгээний бага хурал” боллоо.Онтологийг хослуулах. Онолоос практик хэрэглээ хүртэл".

  • нарийн төвөгтэй бүтээгдэхүүний үйлдвэрлэл, ашиглалт (том механик инженерчлэл, газрын тос, байгалийн хийн үйлдвэрлэл; ихэвчлэн стандартын тухай ярьдаг ISO 15926);

Одоогийн

Энд бас шалтгаан нь сэдвийн талбарын нарийн төвөгтэй байдал юм, жишээлбэл, газрын тос, байгалийн хийн үйлдвэрлэлийн талаар ярих юм бол энгийн нягтлан бодох бүртгэлд CAD функц шаардлагатай байдаг.

2008 онд Chevron компаниас зохион байгуулсан суурилуулалтын төлөөллийн арга хэмжээ болсон бага хурал.

Эцэст нь ISO 15926 нь газрын тос, байгалийн хийн салбарт бага зэрэг хүнд санагдаж байсан (мөн механик инженерчлэлд илүү их хэрэглэгдэх боломжтой). Зөвхөн Statoil (Equinor) л үүнд бүрэн холбогдсон бол Норвегид бүхэлдээ экосистем. Бусад нь өөрсдийнхөө юмыг хийх гэж оролдож байна. Жишээлбэл, цуу ярианы дагуу дотоодын Эрчим хүчний яам нь "түлш, эрчим хүчний цогцолборын онтологийн үзэл баримтлалын загвар" -ыг бий болгохоор төлөвлөж байна. цахилгаан эрчим хүчний салбарт зориулан бүтээгдсэн.

  • санхүүгийн байгууллагууд (XBRL ч гэсэн SDMX ба RDF Data Cube онтологийн нэг төрлийн эрлийз гэж үзэж болно);

Одоогийн

Оны эхээр LinkedIn нь зохиолчийг "Давагдашгүй хүчин зүйл" телевизийн цувралаас мэддэг санхүүгийн салбарын бараг бүх аварга компаниудын сул орон тоогоор идэвхтэй спам болгожээ: Голдман Сакс, JPMorgan Чейз ба/эсвэл Морган Стэнли, Уэллс Фарго, SWIFT/Visa/Mastercard, Bank of America, Citigroup, Fed, Deutsche Bank... Хүн бүр илгээх хүнээ хайж байсан байх. Мэдлэгийн графикийн бага хурал. Цөөн хэд нь олж чадсан: санхүүгийн байгууллагууд бүгдийг нь авсан эхний өдрийн өглөө.

HeadHunter дээр зөвхөн Сбербанк л сонирхолтой зүйл олж харсан бөгөөд энэ нь "RDF-тэй төстэй өгөгдлийн загвар бүхий EAV хадгалах" тухай байв.

Магадгүй дотоодын болон барууны санхүүгийн байгууллагуудын холбогдох технологийг хайрлах түвшний ялгаа нь сүүлийн үеийн үйл ажиллагааны үндэстэн дамнасан шинж чанартай холбоотой байж болох юм. Улсын хилээр интеграци хийх нь чанарын хувьд өөр зохион байгуулалт, техникийн шийдлүүдийг шаарддаг бололтой.

  • арилжааны програмуудтай асуулт хариултын систем (IBM Watson, Apple Siri, Google Knowledge Graph);

Одоогийн

Дашрамд дурдахад, Сири-г бүтээгч Томас Грубер бол онтологийг (IT утгаараа) "үзэл баримтлалын тодорхойлолт" гэсэн тодорхойлолтыг зохиогч юм. Миний бодлоор, энэ тодорхойлолт дахь үгсийг дахин цэгцлэх нь түүний утгыг өөрчлөхгүй бөгөөд энэ нь байхгүй байгааг илтгэж магадгүй юм.

  • бүтэцлэгдсэн өгөгдлийн хэвлэн нийтлэх (илүү үндэслэлтэйгээр үүнийг холбосон нээлттэй өгөгдөлтэй холбож болно).

Одоогийн

Холбогдсон өгөгдлийн томоохон шүтэн бишрэгчид нь GLAM гэж нэрлэгддэг: Галерей, Номын сан, Архив, Музей. Конгрессын номын сан MARC21-ийг орлуулахыг дэмжиж байгааг хэлэхэд хангалттай BIBFRAME, энэ нь Ирээдүйн ном зүйн тайлбарын үндэс суурийг бүрдүүлдэг мөн мэдээж RDF дээр суурилсан.

Википедиа нь DBPedia-аас ялгаатай нь нийтлэлийн мэдээллийн хайрцагнаас импортоор үүсгэгдээгүй, харин Википедиагийн машинд уншигдахуйц хувилбар болох Холбоостой Нээлттэй Мэдээллийн чиглэлээр амжилттай хэрэгжиж буй төслийн жишээ болгон дурддаг. их эсвэл бага гараар үүсгэгдсэн (дараа нь ижил мэдээллийн хайрцагт мэдээллийн эх сурвалж болдог).

Мөн бид танд үүнийг шалгахыг зөвлөж байна жагсаалт Stardog RDF хадгалах сангийн хэрэглэгчид Stardog вэбсайт дээрх "Хэрэглэгчид" хэсэгт.

Gartner-д байсан ч гэсэн Хөгжиж буй технологид зориулсан Hype Cycle 2016 "Аж ахуйн нэгжийн ангилал зүй ба онтологийн менежмент" нь 10 жилийн дараа "бүтээмжийн өндөрлөгт" хүрэх төлөвтэй урам хугарах хөндий рүү уруудах дунд байрладаг.

Байгууллагын өгөгдлийг холбох

Урьдчилан таамаглал, таамаглал, таамаглал ...

Түүхэн сонирхлын үүднээс би Gartner-аас бидний сонирхож буй технологийн талаархи янз бүрийн жилийн таамаглалыг хүснэгтэд оруулав.

Год Технологи Тайлан Албан тушаал Өндөрт он жилүүд
2001 Семантик вэб Хөгжиж буй технологиуд Инновацийн өдөөгч 5-10
2006 Корпорацийн семантик вэб Хөгжиж буй технологиуд Хүлээлтийн оргил үе 5-10
2012 Семантик вэб Их мэдээлэл Хүлээлтийн оргил үе > 10
2015 Холбоотой өгөгдөл Нарийвчилсан аналитик ба мэдээллийн шинжлэх ухаан Урам хугарлын тэвш 5-10
2016 Байгууллагын онтологийн менежмент Хөгжиж буй технологиуд Урам хугарлын тэвш > 10
2018 Мэдлэгийн график Хөгжиж буй технологиуд Инновацийн өдөөгч 5-10

Гэсэн хэдий ч аль хэдийн орсон "Hype Cycle..." 2018 он Өөр нэг өсөх хандлага гарч ирэв - Мэдлэгийн график. Тодорхой хувилгаан бий болсон: эхнийхний хүсэлт, сүүлийнх нь зуршлын нөлөөн дор хэрэглэгчдийн анхаарал, хөгжүүлэгчдийн хүчин чармайлт өөрчлөгдсөн DBMS графикууд нь контур, байрлалыг авч эхлэв. өмнөх өрсөлдөгчдийнх нь .

Бараг бүх график DBMS одоо өөрийгөө корпорацийн "мэдлэгийн график" (холбогдсон өгөгдлийг" заримдаа "холбогдсон өгөгдөл"-ээр сольдог) бүтээхэд тохиромжтой платформ гэж зарлаж байна, гэхдээ ийм нэхэмжлэл хэр үндэслэлтэй вэ?

График өгөгдлийн сангууд нь хэвийн бус хэвээр байгаа бөгөөд DBMS график дахь өгөгдөл нь ижил өгөгдлийн сило хэвээр байна. URI-ийн оронд мөр танигч нь хоёр график DBMS-ийг нэгтгэх ажлыг нэгтгэх ажил хэвээр байгаа бол хоёр RDF дэлгүүрийг нэгтгэх нь ихэвчлэн хоёр RDF графикийг нэгтгэхэд хүргэдэг. Асамантик байдлын өөр нэг тал бол LPG график загварын рефлексгүй байдал бөгөөд энэ нь ижил платформ ашиглан мета өгөгдлийг удирдахад хэцүү болгодог.

Эцэст нь, график DBMS нь дүгнэлтийн хөдөлгүүр эсвэл дүрмийн хөдөлгүүргүй. Ийм хөдөлгүүрийн үр дүнг төвөгтэй асуулга хийх замаар хуулбарлах боломжтой боловч энэ нь SQL дээр ч боломжтой юм.

Гэсэн хэдий ч тэргүүлэгч RDF хадгалах системүүд нь LPG загварыг дэмжихэд хүндрэлтэй байдаггүй. Хамгийн хатуу арга бол Blazegraph-т нэгэн зэрэг санал болгож буй арга юм: RDF болон LPG-ийг хослуулсан RDF* загвар.

Дэлгэрэнгүй

Та Habré дээрх өмнөх нийтлэлээс LPG загварт зориулсан RDF хадгалах хэрэгслийн талаар илүү ихийг уншиж болно. "Одоо RDF санах ойд юу болж байна". Хэзээ нэгэн цагт Мэдлэгийн График ба Өгөгдлийн Фабрикийн талаар тусдаа нийтлэл бичнэ гэж найдаж байна. Эцсийн хэсгийг ойлгоход хялбар тул яаран бичсэн боловч зургаан сарын дараа ч гэсэн эдгээр ойлголтуудын хувьд бүх зүйл тийм ч тодорхой биш байна.

Уран зохиол

  1. Halpin, H., Monnin, A. (eds.) (2014). Философийн инженерчлэл: Вэбийн философи руу
  2. Аллеманг, Д., Хендлер, Ж. (2011) Ажлын онтологичдод зориулсан семантик вэб (2-р хэвлэл)
  3. Staab, S., Studer, R. (eds.) (2009) Handbook on ontology (2-р хэвлэл)
  4. Вуд, D. (ред.). (2011) Аж ахуйн нэгжийн өгөгдлийг холбох
  5. Keet, M. (2018) Онтологийн инженерчлэлийн танилцуулга

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх