Саяхан хэвлэгдсэн энэхүү номноос нэг хэсгийг олон нийтэд толилуулъя.
Аж ахуйн нэгжийн онтологийн загварчлал: арга, технологи [Текст]: монографи / [С. В.Горшков, С.С.Кралин, О.И.Муштак болон бусад; Гүйцэтгэх редактор С.В.Горшков]. - Екатеринбург: Уралын их сургуулийн хэвлэлийн газар, 2019. - 234 х.: өвчтэй, хүснэгт; 20 см - Зохиогч. арын толгойн хэсэгт заасан. -тай. - Ном зүй ch-ийн төгсгөлд. — ISBN 978-5-7996-2580-1: 200 хувь.
Энэ хэсгийг Хабре дээр нийтлэх зорилго нь дөрвөн зүйл юм.
- Хүндэтгэгчийн үйлчлүүлэгч биш бол хэн ч энэ номыг гартаа атгах нь юу л бол
Серж индекс ; Энэ нь мэдээж худалдаанд гарахгүй. - Текстэнд залруулга (доор онцлон тэмдэглээгүй) хийгдсэн бөгөөд хэвлэсэн монографийн форматтай тийм ч нийцэхгүй нэмэлтүүд хийгдсэн: сэдэвчилсэн тэмдэглэл (спойлерын доор) болон гипер холбоосууд.
- Би хүсч байна асуулт, санал цуглуулах, энэ текстийг бусад хэвлэлд шинэчилсэн хэлбэрээр оруулахдаа тэдгээрийг харгалзан үзэхийн тулд.
- Семаль вэб болон холбосон өгөгдлийг дагаж мөрддөг олон хүмүүс өөрсдийн хүрээлэл маш нарийссан гэдэгт итгэдэг бөгөөд гол нь олон нийтэд Семаль вэб болон холбосон өгөгдлийг дагаж мөрддөг байх нь ямар агуу болохыг зөв тайлбарлаагүй байгаа юм. Хэсгийн зохиогч хэдийгээр энэ тойрогт харьяалагддаг ч ийм үзэл бодолтой байдаггүй ч өөрийгөө дахин оролдлого хийх үүрэгтэй гэж үздэг.
Тэгэхээр
Семантик вэб
Интернетийн хувьслыг дараах байдлаар илэрхийлж болно (эсвэл доор заасан дарааллаар үүссэн сегментүүдийн талаар ярих).
- Интернет дэх баримт бичиг. Гол технологиуд - Gopher, FTP гэх мэт.
Интернет бол орон нутгийн нөөцийг солилцох дэлхийн сүлжээ юм. - Интернетийн баримт бичиг. Гол технологи нь HTML болон HTTP юм.
Ил гарсан нөөцийн шинж чанар нь тэдгээрийн дамжуулах орчны шинж чанарыг харгалзан үздэг. - Интернет өгөгдөл. Гол технологиуд - REST ба SOAP API, XHR гэх мэт.
Интернетийн хэрэглээний эрин үе бол зөвхөн хүмүүс нөөцийн хэрэглэгч болж хувирдаггүй. - Интернет өгөгдөл. Гол технологиуд нь Linked Data технологи юм.
Хоёрдахь технологийн гол технологийг бүтээгч, W3C-ийн захирал Бернерс-Лигийн таамагласан энэ дөрөв дэх үе шатыг семантик вэб гэж нэрлэдэг; Холбогдсон өгөгдлийн технологи нь вэб дээрх өгөгдлийг зөвхөн машинд унших боломжтой төдийгүй "машинаар ойлгомжтой" болгох зорилготой юм.
Дараахь зүйлээс уншигч хоёр, дөрөв дэх үе шатны гол ойлголтуудын хоорондын уялдаа холбоог ойлгох болно.
- URL нь URI-тай төстэй,
- HTML-ийн аналог нь RDF,
- HTML гипер холбоосууд нь RDF баримт бичигт URI тохиолдлуудтай төстэй.
Семаль вэб нь тодорхой аяндаа эсвэл лоббиддог чиг хандлагаас илүүтэй интернетийн ирээдүйн талаар системчилсэн төсөөлөл юм, гэхдээ эдгээрийг харгалзан үзэж болно. Жишээлбэл, Вэб 2.0 гэж нэрлэгддэг нэг чухал шинж чанарыг "хэрэглэгчийн үүсгэсэн контент" гэж үздэг. Ялангуяа W3C зөвлөмжид үүнийг анхааралдаа авахыг уриалж байна "
Семаль вэб үхсэн үү?
Хэрэв та татгалзвал
Ерөнхийдөө зохиолч илүү их тархахаас юу сэргийлж байгааг хэлж чадахгүй ч хувийн туршлага дээрээ үндэслэн ярьж болно. 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
Гурвалсан гэж нэрлэгддэг "субъект-предикат-объект" төрлийн мэдэгдлүүд нь аж ахуйн нэгжүүд болон тэдгээрийн харилцааны талаар хийгдсэн байдаг. Хамгийн энгийн тохиолдолд субьект, предикат, объект нь бүгд URI юм. Нэг URI нь өөр өөр гурвалсан байрлалд байж болно: субьект, предикат, объект байх; Ийнхүү гурвалсанууд нь RDF график гэж нэрлэгддэг нэг төрлийн график үүсгэдэг.
Субъектууд болон объектууд нь зөвхөн URI биш, бас гэж нэрлэгддэг байж болно хоосон зангилаа, мөн объектууд бас байж болно үг хэллэг. Литерал гэдэг нь мөрийн дүрслэл болон төрлийн заалтаас бүрдэх энгийн төрлүүдийн жишээ юм.
Бичиг үсэг бичих жишээнүүд (Мэлхий синтакс дээр доороос дэлгэрэнгүй авч үзнэ үү): "5.0"^^xsd:float
и "five"^^xsd:string
. Төрөлтэй үсэг rdf:langString
Мөн хэлний шошготой байж болно; яст мэлхий дээр дараах байдлаар бичигдсэн байдаг. "five"@en
и "пять"@ru
.
Хоосон зангилаанууд нь дэлхийн танигчгүй "нэргүй" нөөц бөгөөд тэдгээрийн талаар мэдэгдэл хийх боломжтой; оршин тогтнох хувьсагчдын төрөл.
Тиймээс (энэ нь үнэндээ RDF-ийн бүх санаа юм):
- сэдэв нь URI эсвэл хоосон зангилаа,
- предикат нь URI,
- объект нь URI, хоосон зангилаа эсвэл литерал юм.
Яагаад предикатууд хоосон зангилаа байж болохгүй гэж?
Болзошгүй шалтгаан нь гурвалсан утгыг албан бусаар ойлгож, нэгдүгээр зэрэглэлийн предикатын логик хэл рүү орчуулах хүсэл юм. s p o
гэх мэт хаана - предикат, и - тогтмолууд. Энэхүү ойлголтын ул мөр баримт бичигт бий”s p []
хаана []
- хоосон зангилаа, гэж орчуулагдах болно хаана - хувьсагч, гэхдээ яаж орчуулах вэ s [] o
? W3C зөвлөмжийн статустай баримт бичиг "
Гэсэн хэдий ч Ману Спорни
RDF бол хийсвэр загвар юм. RDF-ийг янз бүрийн синтаксаар бичиж болно (цувралчилсан):
Ижил 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
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 нь тайлбар, загварчлах үгсийн сан боловч хязгаарлагдмал хэл биш (хэдийгээр албан ёсны тодорхойлолт болон :author rdfs:range foaf:Person
гэсэн үг rdf:type
бүх үл хөдлөх хөрөнгийн үнэ цэнэ :author
- foaf:Person
, гэхдээ үүнийг урьдчилан хэлэх ёстой гэсэн үг биш юм.
SPARQL
Асуулга нь ийм хувьсагчийн утгуудыг буцаана, түүвэрт орлуулснаар асуусан RDF графикийн дэд график (түүний гурвалсан дэд хэсэг) гарч ирнэ. Гурвалсан хүүхдийн өөр өөр түүврийн ижил нэртэй хувьсагчид ижил утгатай байх ёстой.
Жишээлбэл, дээрх долоон RDFS аксиомыг өгвөл дараах асуулга буцах болно rdfs:domain
и rdfs:range
үнэт зүйлс болгон ?s
и ?p
тус тус:
SELECT * WHERE {
?s ?p rdfs:Class .
?p ?p rdf:Property .
}
SPARQL нь тунхаглах шинж чанартай бөгөөд графикаар дамждаг хэл биш гэдгийг тэмдэглэх нь зүйтэй (гэхдээ зарим RDF репозиторууд асуулгын гүйцэтгэлийн төлөвлөгөөг тохируулах аргыг санал болгодог). Тиймээс хамгийн богино замыг олох гэх мэт стандарт графикийн зарим асуудлыг SPARQL-д шийдвэрлэх боломжгүй.
SPARQL нь дэлхийн нээлттэй байдлын таамаглалыг хуваалцдаггүй бөгөөд "үгүйсгэхийг бүтэлгүйтэл" гэж үздэг. FILTER NOT EXISTS {…}
. Мэдээллийн хуваарилалтыг механизмыг ашиглан тооцдог
SPARQL хандалтын цэг - SPARQL асуулга боловсруулах чадвартай RDF хадгалах сан нь хоёр дахь шатнаас шууд аналоггүй (энэ догол мөрийн эхлэлийг үзнэ үү). Үүнийг HTML хуудсуудыг үүсгэсэн агуулгаар нь өгөгдлийн сантай зүйрлэж болох боловч гаднаас нь үзэх боломжтой. SPARQL хандалтын цэг нь гурав дахь шатны API хандалтын цэгтэй илүү төстэй боловч үндсэн хоёр ялгаатай. Нэгдүгээрт, хэд хэдэн "атомын" асуулгад нэгтгэх боломжтой (энэ нь GraphQL-ийн гол шинж чанар гэж тооцогддог), хоёрдугаарт, ийм API нь өөрөө өөрийгөө баримтжуулдаг (үүнийг HATEOAS хүрэх гэж оролдсон).
Полемик тайлбар
RDF нь вэб дээр өгөгдлийг нийтлэх арга тул RDF хадгалалтыг баримт бичгийн DBMS гэж үзэх хэрэгтэй. Үнэн бол RDF нь мод биш харин график учраас тэдгээр нь график дээр суурилсан байсан нь үнэн. Энэ нь үнэхээр амжилттай болсон нь гайхалтай. Хоосон зангилаа хэрэгжүүлдэг ухаалаг хүмүүс байна гэж хэн санах билээ. Кодд энд байна
RDF-ийн өгөгдөлд хандах хандалтыг зохион байгуулах бүрэн боломж багатай аргууд байдаг, жишээлбэл,
OWL
OWL-д тайлбарлах логикийн тухай ойлголтууд нь ангиудад, үүрэг нь шинж чанаруудтай тохирч, хувь хүмүүс өмнөх нэрээ хадгалдаг. Аксиомуудыг аксиом гэж бас нэрлэдэг.
Жишээлбэл, гэж нэрлэгддэг зүйлд
Class: Human
Class: Parent
EquivalentClass: Human and (inverse hasParent) some Human
ObjectProperty: hasParent
гэх мэт OWL бичих өөр синтаксууд байдаг
OWL нь RDF-тэй хос харилцаатай байдаг. Энэ нь нэг талаас RDFS-ийг өргөтгөсөн нэг төрлийн толь бичиг гэж үзэж болно. Нөгөө талаас, энэ нь RDF нь зүгээр л цуваа формат болох илүү хүчирхэг формализм юм. Бүх энгийн OWL бүтцийг нэг RDF триплет ашиглан бичиж болохгүй.
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-ийг орлуулахыг дэмжиж байгааг хэлэхэд хангалттай
Википедиа нь DBPedia-аас ялгаатай нь нийтлэлийн мэдээллийн хайрцагнаас импортоор үүсгэгдээгүй, харин Википедиагийн машинд уншигдахуйц хувилбар болох Холбоостой Нээлттэй Мэдээллийн чиглэлээр амжилттай хэрэгжиж буй төслийн жишээ болгон дурддаг. их эсвэл бага гараар үүсгэгдсэн (дараа нь ижил мэдээллийн хайрцагт мэдээллийн эх сурвалж болдог).
Мөн бид танд үүнийг шалгахыг зөвлөж байна
Gartner-д байсан ч гэсэн
Байгууллагын өгөгдлийг холбох
Урьдчилан таамаглал, таамаглал, таамаглал ...
Түүхэн сонирхлын үүднээс би Gartner-аас бидний сонирхож буй технологийн талаархи янз бүрийн жилийн таамаглалыг хүснэгтэд оруулав.
Год | Технологи | Тайлан | Албан тушаал | Өндөрт он жилүүд |
---|---|---|---|---|
2001 | Семантик вэб | Хөгжиж буй технологиуд | Инновацийн өдөөгч | 5-10 |
2006 | Корпорацийн семантик вэб | Хөгжиж буй технологиуд | Хүлээлтийн оргил үе | 5-10 |
2012 | Семантик вэб | Их мэдээлэл | Хүлээлтийн оргил үе | > 10 |
2015 | Холбоотой өгөгдөл | Нарийвчилсан аналитик ба мэдээллийн шинжлэх ухаан | Урам хугарлын тэвш | 5-10 |
2016 | Байгууллагын онтологийн менежмент | Хөгжиж буй технологиуд | Урам хугарлын тэвш | > 10 |
2018 | Мэдлэгийн график | Хөгжиж буй технологиуд | Инновацийн өдөөгч | 5-10 |
Гэсэн хэдий ч аль хэдийн орсон
Бараг бүх график DBMS одоо өөрийгөө корпорацийн "мэдлэгийн график" (холбогдсон өгөгдлийг" заримдаа "холбогдсон өгөгдөл"-ээр сольдог) бүтээхэд тохиромжтой платформ гэж зарлаж байна, гэхдээ ийм нэхэмжлэл хэр үндэслэлтэй вэ?
График өгөгдлийн сангууд нь хэвийн бус хэвээр байгаа бөгөөд DBMS график дахь өгөгдөл нь ижил өгөгдлийн сило хэвээр байна. URI-ийн оронд мөр танигч нь хоёр график DBMS-ийг нэгтгэх ажлыг нэгтгэх ажил хэвээр байгаа бол хоёр RDF дэлгүүрийг нэгтгэх нь ихэвчлэн хоёр RDF графикийг нэгтгэхэд хүргэдэг. Асамантик байдлын өөр нэг тал бол LPG график загварын рефлексгүй байдал бөгөөд энэ нь ижил платформ ашиглан мета өгөгдлийг удирдахад хэцүү болгодог.
Эцэст нь, график DBMS нь дүгнэлтийн хөдөлгүүр эсвэл дүрмийн хөдөлгүүргүй. Ийм хөдөлгүүрийн үр дүнг төвөгтэй асуулга хийх замаар хуулбарлах боломжтой боловч энэ нь SQL дээр ч боломжтой юм.
Гэсэн хэдий ч тэргүүлэгч RDF хадгалах системүүд нь LPG загварыг дэмжихэд хүндрэлтэй байдаггүй. Хамгийн хатуу арга бол Blazegraph-т нэгэн зэрэг санал болгож буй арга юм: RDF болон LPG-ийг хослуулсан RDF* загвар.
Дэлгэрэнгүй
Та Habré дээрх өмнөх нийтлэлээс LPG загварт зориулсан RDF хадгалах хэрэгслийн талаар илүү ихийг уншиж болно.
Уран зохиол
- Halpin, H., Monnin, A. (eds.) (2014). Философийн инженерчлэл: Вэбийн философи руу
- Аллеманг, Д., Хендлер, Ж. (2011) Ажлын онтологичдод зориулсан семантик вэб (2-р хэвлэл)
- Staab, S., Studer, R. (eds.) (2009) Handbook on ontology (2-р хэвлэл)
- Вуд, D. (ред.). (2011) Аж ахуйн нэгжийн өгөгдлийг холбох
- Keet, M. (2018) Онтологийн инженерчлэлийн танилцуулга
Эх сурвалж: www.habr.com