เว็บความหมายและข้อมูลเชื่อมโยง การแก้ไขและเพิ่มเติม

ฉันต้องการนำเสนอส่วนหนึ่งของหนังสือที่ตีพิมพ์เมื่อเร็ว ๆ นี้ต่อสาธารณชน:

การสร้างแบบจำลองทางอภิปรัชญาขององค์กร: วิธีการและเทคโนโลยี [ข้อความ]: เอกสาร / [S. V. Gorshkov, S. S. Kralin, O. I. Mushtak และคนอื่น ๆ ; บรรณาธิการบริหาร S. V. Gorshkov]. - Yekaterinburg: สำนักพิมพ์แห่งมหาวิทยาลัย Ural, 2019 - 234 p.: ill., tab.; 20 ซม. - รับรองความถูกต้อง ระบุไว้ที่ด้านหลังของหัวนม กับ. — ผู้เขียนบรรณานุกรม ท้ายช. - ISBN 978-5-7996-2580-1: 200 เล่ม

จุดประสงค์ของการจัดวางส่วนนี้บนHabréมีสี่ประการ:

• ไม่น่าเป็นไปได้ที่ใครบางคนจะสามารถถือหนังสือเล่มนี้ไว้ในมือได้หากเขาไม่ใช่ลูกค้าของผู้เคารพนับถือ เสิร์จอินเด็กซ์; มันไม่ขายแน่นอน
• มีการแก้ไขข้อความ (ไม่ได้เน้นด้านล่าง) และมีการเพิ่มเติมที่ไม่เข้ากันกับรูปแบบของเอกสารที่พิมพ์: บันทึกเฉพาะ (ภายใต้สปอยเลอร์) และไฮเปอร์ลิงก์
• ฉันต้องการที่จะ รวบรวมคำถามและความคิดเห็นเพื่อนำมาพิจารณาเมื่อข้อความนี้รวมอยู่ในแบบฟอร์มที่แก้ไขในฉบับอื่นๆ
• ผู้ติดตาม Semantic Web และข้อมูลที่เชื่อมโยงจำนวนมากยังคงรู้สึกว่าวงกลมของพวกเขาแคบมาก ส่วนใหญ่เป็นเพราะประชาชนทั่วไปยังไม่ได้รับการอธิบายอย่างถูกต้องว่าการเป็นผู้ปฏิบัติตาม Semantic Web และข้อมูลที่เชื่อมโยงนั้นดีเพียงใด ผู้เขียนชิ้นส่วนแม้ว่าเขาจะอยู่ในแวดวงนี้ แต่ก็ไม่ยึดติดกับความคิดเห็นดังกล่าว แต่อย่างไรก็ตามคิดว่าตัวเองจำเป็นต้องพยายามอีกครั้ง

ดังนั้น

เว็บความหมาย

วิวัฒนาการของอินเทอร์เน็ตสามารถแสดงได้ดังต่อไปนี้ (หรือพูดคุยเกี่ยวกับส่วนต่างๆ ที่เกิดขึ้นตามลำดับต่อไปนี้):

1. เอกสารบนอินเทอร์เน็ต. เทคโนโลยีหลัก - Gopher, FTP ฯลฯ
   อินเทอร์เน็ตเป็นเครือข่ายระดับโลกสำหรับการแลกเปลี่ยนทรัพยากรในท้องถิ่น
2. เอกสารทางอินเทอร์เน็ต. เทคโนโลยีหลักคือ HTML และ HTTP
   ลักษณะของทรัพยากรที่เปิดเผยนั้นคำนึงถึงลักษณะของตัวกลางสำหรับการส่งผ่าน
3. ข้อมูลอินเทอร์เน็ต. เทคโนโลยีที่สำคัญคือ REST และ SOAP API, XHR เป็นต้น
   ยุคของการใช้งานอินเทอร์เน็ตไม่เพียง แต่ผู้คนกลายเป็นผู้บริโภคทรัพยากร
4. ข้อมูลอินเทอร์เน็ต. เทคโนโลยีที่สำคัญคือเทคโนโลยีข้อมูลที่เชื่อมโยง
   ขั้นตอนที่สี่นี้ ทำนายโดย Berners-Lee ผู้สร้างเทคโนโลยีหลักของขั้นตอนที่สองและผู้อำนวยการ W3C เรียกว่า Semantic Web; เทคโนโลยี Linked Data ได้รับการออกแบบมาเพื่อทำให้ข้อมูลบนเว็บไม่เพียงสามารถอ่านได้ด้วยเครื่องเท่านั้น แต่ยัง "สามารถเข้าใจด้วยเครื่อง" ได้อีกด้วย

จากสิ่งต่อไปนี้ ผู้อ่านจะเห็นได้ชัดว่าแนวคิดหลักของขั้นตอนที่สองและสี่สอดคล้องกัน:

• อะนาล็อกของ URL คือ URIs
• HTML นั้นคล้ายคลึงกับ RDF
• ไฮเปอร์ลิงก์ HTML คล้ายกับรายการ URI ในเอกสาร RDF

Semantic Web เป็นการมองเห็นอนาคตของอินเทอร์เน็ตอย่างเป็นระบบมากกว่าแนวโน้มที่เกิดขึ้นเองหรือโน้มน้าวใจ แม้ว่าจะสามารถคำนึงถึงสิ่งหลังเหล่านี้ได้เช่นกัน ตัวอย่างเช่น "เนื้อหาที่ผู้ใช้สร้างขึ้น" ถือเป็นคุณลักษณะที่สำคัญของสิ่งที่เรียกว่า Web 2.0 มีการเรียกร้องให้คำนึงถึง โดยเฉพาะอย่างยิ่ง คำแนะนำของ W3C "ออนโทโลยีคำอธิบายประกอบเว็บ"และการดำเนินการเช่น ของแข็ง.

Semantic Web ตายแล้วหรือ?

ถ้าคุณปฏิเสธ ความคาดหวังที่ไม่สมจริงสถานการณ์ของเว็บความหมายนั้นใกล้เคียงกับลัทธิคอมมิวนิสต์ในสมัยของสังคมนิยมที่พัฒนาแล้ว (และให้ทุกคนตัดสินใจด้วยตัวเองว่าจะปฏิบัติตามกฎเงื่อนไขของ Ilyich หรือไม่) เครื่องมือค้นหา ค่อนข้างประสบความสำเร็จ บังคับให้เว็บไซต์ใช้ RDFa และ JSON-LD และใช้เทคโนโลยีที่เกี่ยวข้องกับที่อธิบายไว้ด้านล่าง (กราฟความรู้ของ Google, กราฟความรู้ของ Bing)

โดยทั่วไป ผู้เขียนไม่สามารถพูดได้ว่าสิ่งใดขัดขวางการเผยแพร่มากขึ้น แต่เขาสามารถพูดบนพื้นฐานของประสบการณ์ส่วนตัว มีงานที่ต้องแก้ไข "นอกกรอบ" ในเงื่อนไขของ SW ที่น่ารังเกียจแม้ว่าจะไม่ใหญ่มากก็ตาม เป็นผลให้ผู้ที่มีงานเหล่านี้ไม่มีวิธีการบังคับกับผู้ที่สามารถจัดหาวิธีแก้ปัญหาได้และฝ่ายหลังเองก็ให้วิธีแก้ปัญหาโดยฝ่ายหลังซึ่งตรงกันข้ามกับรูปแบบธุรกิจของพวกเขา ดังนั้นเราจึงยังคงแยกวิเคราะห์ HTML และกาว API ต่างๆ ต่อไป

อย่างไรก็ตาม เทคโนโลยีข้อมูลที่เชื่อมโยงได้แพร่กระจายไปไกลกว่าเว็บขนาดใหญ่ อันที่จริงแล้วหนังสือเล่มนี้อุทิศให้กับการสมัครของพวกเขา ในปัจจุบัน ชุมชน Linked Data คาดว่าเทคโนโลยีเหล่านี้จะแพร่หลายมากยิ่งขึ้นด้วย Gartner ที่กำหนดแนวโน้ม (หรือประกาศแล้วแต่คุณจะชอบ) เช่น กราฟความรู้ и ผ้าข้อมูล. ฉันอยากจะเชื่อว่าการนำแนวคิดเหล่านี้ไปใช้ "จักรยาน" จะไม่ประสบความสำเร็จ แต่เกี่ยวข้องกับมาตรฐาน W3C ที่กล่าวถึงด้านล่าง

ข้อมูลที่เชื่อมโยง

Berners-Lee ให้คำจำกัดความของ Linked Data ว่าเป็น Semantic Web ที่ถูกต้อง: ชุดของแนวทางและเทคโนโลยีเพื่อให้บรรลุเป้าหมายสูงสุด หลักการพื้นฐานของข้อมูลที่เชื่อมโยง Berners-Lee แยกออกมา กำลังติดตาม.

หลักการ 1. การใช้ URIs เพื่อตั้งชื่อเอนทิตี

URIs เป็นตัวระบุเอนทิตีส่วนกลางซึ่งตรงข้ามกับตัวระบุสตริงในเครื่องของรายการ ต่อจากนั้น หลักการนี้พบการแสดงออกที่ดีที่สุดในสโลแกนของกราฟความรู้ของ Google “สิ่งต่าง ๆ ไม่ใช่สตริง'

หลักการ 2. การใช้ URIs ในรูปแบบ HTTP เพื่อให้สามารถอ้างอิงได้

เมื่ออ้างอิงถึง URI ควรจะได้ตัวระบุที่อยู่ด้านหลังตัวระบุนั้น (การเปรียบเทียบกับชื่อของตัวดำเนินการ “*» ใน C); แม่นยำยิ่งขึ้น เพื่อรับการแทนความหมายนี้ - ขึ้นอยู่กับค่าของส่วนหัว HTTP Accept:. บางทีด้วยการกำเนิดของยุค AR / VR จะเป็นไปได้ที่จะได้รับทรัพยากร แต่สำหรับตอนนี้น่าจะเป็นเอกสาร RDF ที่เป็นผลมาจากแบบสอบถาม SPARQL DESCRIBE.

หลักการ 3. การใช้มาตรฐาน W3C - RDF(S) และ SPARQL เป็นหลัก - โดยเฉพาะอย่างยิ่งเมื่อมีการอ้างอิง URIs

"ชั้น" แต่ละชั้นของสแต็กเทคโนโลยีข้อมูลที่เชื่อมโยงหรือที่เรียกว่า เค้กเลเยอร์เว็บความหมายจะอธิบายไว้ด้านล่าง

หลักการ 4. การใช้การอ้างอิงไปยัง URI อื่นเมื่ออธิบายเอนทิตี

RDF อนุญาตให้คุณจำกัดตัวเองในการอธิบายด้วยวาจาของทรัพยากรในภาษาธรรมชาติ และหลักการข้อที่สี่เรียกร้องให้ไม่ทำเช่นนี้ ด้วยการปฏิบัติตามหลักการข้อแรกที่เป็นสากล จึงเป็นไปได้ที่จะอ้างถึงผู้อื่น รวมถึง "มนุษย์ต่างดาว" เมื่ออธิบายทรัพยากร ซึ่งเป็นสาเหตุที่ข้อมูลถูกเรียกว่าเชื่อมโยง ในความเป็นจริง แทบจะหลีกเลี่ยงไม่ได้ที่จะใช้ URI ที่มีชื่ออยู่ในพจนานุกรม RDFS

RDF

RDF (กรอบคำอธิบายทรัพยากร) - พิธีการสำหรับการอธิบายหน่วยงานที่เกี่ยวข้องกัน

เกี่ยวกับเอนทิตีและความสัมพันธ์จะมีการจัดทำคำแถลงในรูปแบบ "หัวเรื่อง - กริยา - วัตถุ" เรียกว่าแฝด ในกรณีที่ง่ายที่สุด หัวเรื่อง เพรดิเคต และออบเจกต์เป็น URI ทั้งคู่ URI เดียวกันสามารถอยู่ในสามแฝดที่แตกต่างกันในตำแหน่งที่แตกต่างกัน: เป็นเรื่อง ภาคแสดง และวัตถุ; แฝดสามจึงสร้างกราฟชนิดหนึ่งที่เรียกว่ากราฟ RDF

หัวเรื่องและวัตถุสามารถเป็นได้ทั้ง URIs แต่ยังเรียกว่า โหนดว่างและวัตถุได้อีกด้วย อักษร. ตัวอักษรเป็นอินสแตนซ์ของประเภทดั้งเดิม ซึ่งประกอบด้วยการแสดงสตริงและข้อมูลจำเพาะประเภท

ตัวอย่างของการเขียนตัวอักษร (ในไวยากรณ์ของ Turtle เพิ่มเติมด้านล่าง): "5.0"^^xsd:float и "five"^^xsd:string. ตัวอักษรที่มีประเภท rdf:langString สามารถระบุแท็กภาษาได้ด้วย ใน Turtle จะเขียนดังนี้: "five"@en и "пять"@ru.

โหนดว่างเป็นทรัพยากร "ไม่ระบุชื่อ" โดยไม่มีตัวระบุส่วนกลาง ซึ่งสามารถยืนยันได้ ประเภทของตัวแปรที่มีอยู่

ดังนั้น (นี่คือสาระสำคัญทั้งหมดของ RDF):

• หัวเรื่องคือ URI หรือโหนดว่าง
• เพรดิเคตคือ URI
• วัตถุคือ URI โหนดว่างหรือตัวอักษร

เหตุใดเพรดิเคตจึงเป็นโหนดว่างไม่ได้

เหตุผลที่น่าจะเป็นคือความปรารถนาที่จะเข้าใจอย่างไม่เป็นทางการและแปล triplet เป็นภาษาของตรรกะภาคแสดงลำดับที่หนึ่ง s p o เหมือนอะไรซักอย่าง ที่ไหน - เพรดิเคต и - ค่าคงที่ มีร่องรอยของความเข้าใจดังกล่าวในเอกสาร “LBase: ความหมายสำหรับภาษาของเว็บความหมาย” ซึ่งมีสถานะเป็นบันทึกของคณะทำงาน W3C ด้วยความเข้าใจนี้แฝดสาม s p []ที่ไหน [] - โหนดว่างจะถูกแปลเป็น ที่ไหน - ตัวแปรแล้วแต่ว่าจะแปลอย่างไร s [] o? เอกสารแนะนำ W3C "RDF 1.1 ความหมาย” แนะนำวิธีการแปลแบบอื่น แต่ยังไม่พิจารณาถึงความเป็นไปได้ที่เพรดิเคตจะเป็นโหนดว่าง

อย่างไรก็ตามมนุษญ์ อนุญาต.

RDF เป็นรูปแบบนามธรรม RDF สามารถเขียน (ซีเรียลไลซ์) ในไวยากรณ์ต่างๆ: RDF/XML, เต่า (มนุษย์ส่วนใหญ่อ่านได้) JSON-LD, เอชดีที (ไบนารี่).

RDF เดียวกันสามารถถูกทำให้เป็นอนุกรมเป็น RDF/XML ได้หลายวิธี ดังนั้นจึงไม่มีเหตุผลที่จะตรวจสอบความถูกต้องของ XML ที่เป็นผลลัพธ์ด้วย XSD หรือพยายามแยกข้อมูลด้วย 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.

อาร์ดีเอฟเอส

อาร์ดีเอฟเอส (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 Protocol และ 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 ซึ่งเป็นที่เก็บ RDF ที่สามารถประมวลผลการสืบค้น SPARQL ได้ ไม่มีแอนะล็อกโดยตรงจากขั้นตอนที่สอง (ดูที่จุดเริ่มต้นของย่อหน้านี้) สามารถเปรียบได้กับฐานข้อมูล โดยอ้างอิงจากเนื้อหาที่สร้างหน้า HTML แต่ภายนอกสามารถเข้าถึงได้ จุดเชื่อมต่อ SPARQL เป็นเหมือนจุดเชื่อมต่อ API จากขั้นตอนที่สาม แต่มีความแตกต่างหลักสองประการ ประการแรก เป็นไปได้ที่จะรวมข้อความค้นหา "atomic" หลายรายการเป็นหนึ่งเดียว (ซึ่งถือเป็นลักษณะสำคัญของ GraphQL) และประการที่สอง API ดังกล่าวมีการจัดทำเอกสารด้วยตนเองอย่างสมบูรณ์ (ซึ่ง HATEOAS พยายามบรรลุ)

ข้อสังเกตเชิงโต้เถียง

RDF เป็นวิธีการเผยแพร่ข้อมูลบนเว็บ ดังนั้นที่เก็บ RDF ควรถือเป็น DBMS ของเอกสาร จริง เนื่องจาก RDF เป็นกราฟ ไม่ใช่ต้นไม้ จึงกลายเป็นกราฟในเวลาเดียวกัน มันวิเศษมากที่มันได้ผล ใครจะคิดว่าจะมีคนฉลาดที่ใช้โหนดเปล่า นี่คือคอดด์ ไม่ได้ผล.

นอกจากนี้ยังมีวิธีการจัดระเบียบการเข้าถึงข้อมูล RDF ที่มีคุณลักษณะครบถ้วนน้อยกว่า เช่น ส่วนข้อมูลที่เชื่อมโยง (แอลดีเอฟ)และ แพลตฟอร์มข้อมูลที่เชื่อมโยง (แอลดีพี).

นกฮูก

นกฮูก (ภาษาออนโทโลจีของเว็บ) - พิธีการของการแสดงความรู้ ซึ่งเป็นรูปแบบวากยสัมพันธ์ของตรรกะเชิงพรรณนา (ทุกที่ด้านล่างจะถูกต้องกว่าที่จะพูดว่า 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 triplet ตัวเดียว

ขึ้นอยู่กับชุดย่อยของโครงสร้าง OWL ที่อนุญาตให้ใช้ หนึ่งพูดถึงสิ่งที่เรียกว่า โปรไฟล์นกฮูก. มาตรฐานและเป็นที่รู้จักดีที่สุดคือ OWL EL, OWL RL และ OWL QL การเลือกโปรไฟล์ส่งผลต่อความซับซ้อนในการคำนวณของปัญหาทั่วไป การออกแบบ OWL ครบชุดเพื่อให้เข้ากัน เรียกว่า OWL DL บางครั้งใคร ๆ ก็พูดถึง OWL Full ซึ่งโครงสร้าง OWL ได้รับอนุญาตให้ใช้อย่างอิสระเต็มที่ใน RDF โดยไม่มีข้อจำกัดด้านความหมายและการคำนวณ . ตัวอย่างเช่น บางสิ่งบางอย่างสามารถเป็นได้ทั้งคลาสและคุณสมบัติ OWL เต็มไม่สามารถแก้ไขได้

หลักการสำคัญของการแนบผลลัพธ์ใน OWL คือการยอมรับสมมติฐานโลกเปิด (สมมติฐานโลกเปิด OWA) และการปฏิเสธสมมติฐานชื่อเฉพาะ UNA). ด้านล่างเราจะดูว่าหลักการเหล่านี้สามารถนำไปสู่อะไรและแนะนำโครงสร้างของ OWL

ให้ ontology มีแฟรกเมนต์ต่อไปนี้ (ในไวยากรณ์ของแมนเชสเตอร์):

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

ตอนนี้ให้ส่วนของ ontology มีรูปแบบดังต่อไปนี้ (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 }

ตอนนี้ ontology จะไม่สอดคล้องกัน ซึ่งเครื่องมืออนุมานจะไม่ล้มเหลวในการรายงาน ด้วยสัจพจน์สุดท้าย เราค่อนข้าง "ปิด" โลกและสังเกตว่าความเป็นไปได้ที่จอห์นจะเป็นลูกของเขาเองนั้นถูกตัดออกไป

การเชื่อมโยงข้อมูลองค์กร

ชุดของแนวทางและเทคโนโลยี Linked Data เดิมมีไว้สำหรับการเผยแพร่ข้อมูลบนเว็บ การใช้งานในสภาพแวดล้อมแบบรวมองค์กรต้องเผชิญกับปัญหาหลายประการ

ตัวอย่างเช่น ในสภาพแวดล้อมแบบองค์กรแบบปิด อำนาจแบบนิรนัยของ OWL ตามการยอมรับของ OWA และการปฏิเสธของ UNA ซึ่งเป็นโซลูชันที่ขับเคลื่อนโดยธรรมชาติแบบเปิดและแบบกระจายของเว็บนั้นอ่อนแอเกินไป และนี่คือผลลัพธ์ที่เป็นไปได้

• มอบความหมายของ OWL ซึ่งบ่งบอกถึงการปฏิเสธ OWA และการยอมรับ UNA ซึ่งเป็นการนำกลไกการอนุมานที่สอดคล้องกันไปใช้ - ตามเส้นทางนี้ กำลังมา พื้นที่เก็บข้อมูล Stardog RDF
• ละทิ้งอำนาจนิรนัยของ OWL เพื่อสนับสนุนเครื่องยนต์กฎ - รองรับ Stardog สว; ข้อเสนอของ Jena และ GraphDB ด้วยตัวเอง ภาษา กฎ.
• การปฏิเสธความสามารถแบบนิรนัยของ OWL การใช้ชุดย่อยหนึ่งหรือชุดอื่นที่ใกล้เคียงกับ RDFS สำหรับการสร้างแบบจำลอง - ดูเพิ่มเติมเกี่ยวกับสิ่งนี้ด้านล่าง

ปัญหาอีกประการหนึ่งคือความใส่ใจที่สำคัญกว่าที่โลกธุรกิจสามารถทุ่มเทให้กับปัญหาด้านคุณภาพของข้อมูลและการขาดเครื่องมือตรวจสอบความถูกต้องของข้อมูลในสแต็กข้อมูลที่เชื่อมโยง ผลลัพธ์มีดังนี้

• อีกครั้ง โดยใช้โครงสร้าง OWL ที่มีความหมายแบบโลกปิดและเอกลักษณ์ของชื่อเพื่อตรวจสอบว่ามีกลไกการอนุมานที่เหมาะสมหรือไม่
• ใช้ แชคแอลให้เป็นมาตรฐานหลังจากรายการเลเยอร์ Semantic Web Layer Cake ได้รับการแก้ไขแล้ว (แต่สามารถใช้เป็นกลไกกฎได้) หรือ เช็กซ์.
• เมื่อตระหนักว่าท้ายที่สุดแล้วทุกสิ่งเสร็จสิ้นโดยแบบสอบถาม SPARQL สร้างกลไกการตรวจสอบข้อมูลอย่างง่ายของคุณเองโดยใช้กลไกเหล่านี้

อย่างไรก็ตาม แม้แต่การปฏิเสธความสามารถแบบนิรนัยและเครื่องมือการตรวจสอบอย่างสมบูรณ์ก็ยังทำให้สแต็กข้อมูลที่เชื่อมโยงไม่อยู่ในการแข่งขันในงานที่มีแนวนอนคล้ายกับงานรวมข้อมูลบนเว็บแบบเปิดและแบบกระจาย

ระบบข้อมูลองค์กรปกติเป็นอย่างไร?

สิ่งนี้เป็นไปได้ แต่แน่นอนว่าควรตระหนักว่าปัญหาใดที่เทคโนโลยีที่เหมาะสมจะต้องแก้ไข ฉันจะอธิบายปฏิกิริยาโดยทั่วไปของผู้เข้าร่วมการพัฒนาเพื่อแสดงให้เห็นว่ากลุ่มเทคโนโลยีนี้มีลักษณะอย่างไรจากมุมมองของไอทีทั่วไป ทำให้ฉันนึกถึงคำอุปมาเรื่องช้าง:

• นักวิเคราะห์ธุรกิจ: RDF เป็นเหมือนโมเดลตรรกะที่เก็บไว้โดยตรง
• นักวิเคราะห์ระบบ: RDF ก็เหมือน อีเอวีด้วยดัชนีจำนวนมากและภาษาสืบค้นที่สะดวกเท่านั้น
• ผู้พัฒนา: ทั้งหมดนี้อยู่ในจิตวิญญาณของโมเดลที่สมบูรณ์และแนวคิดโค้ดต่ำ กำลังอ่าน เกี่ยวกับมันเมื่อเร็ว ๆ นี้
• ผู้จัดการโครงการ: ใช่แล้ว ยุบกอง!

การปฏิบัติแสดงให้เห็นว่าสแตกมักใช้ในงานที่เกี่ยวข้องกับการกระจายและความแตกต่างของข้อมูล ตัวอย่างเช่น เมื่อสร้างระบบของคลาส MDM (การจัดการข้อมูลหลัก) หรือ DWH (คลังข้อมูล) ปัญหาดังกล่าวมีอยู่ในทุกอุตสาหกรรม

สำหรับแอปพลิเคชันเฉพาะอุตสาหกรรม ปัจจุบันเทคโนโลยี Linked Data ได้รับความนิยมมากที่สุดในอุตสาหกรรมต่อไปนี้

• เทคโนโลยีชีวการแพทย์ (ซึ่งความนิยมดูเหมือนจะเกี่ยวข้องกับความซับซ้อนของสาขาวิชา);

เฉพาะที่

ใน "จุดเดือด" เมื่อวันก่อนการประชุมที่จัดโดยสมาคม "ฐานความรู้ทางการแพทย์แห่งชาติ" จัดขึ้น "การรวมกันของออนโทโลยี จากภาคทฤษฎีสู่ภาคปฏิบัติ'

• การผลิตและการดำเนินงานของผลิตภัณฑ์ที่ซับซ้อน (วิศวกรรมขนาดใหญ่ การผลิตน้ำมันและก๊าซ ส่วนใหญ่มักจะเป็นมาตรฐาน ISO.15926);

เฉพาะที่

เหตุผลก็คือความซับซ้อนของสาขาวิชา เช่น ในระดับต้นน้ำ หากเราพูดถึงอุตสาหกรรมน้ำมันและก๊าซ การบัญชีอย่างง่ายจำเป็นต้องมีฟังก์ชัน CAD บางอย่าง

ในปี พ.ศ. 2008 เชฟรอนเป็นเจ้าภาพในการติดตั้งตัวแทน การประชุม.

ในที่สุด ISO 15926 ก็ดูจะหนักไปหน่อยสำหรับอุตสาหกรรมน้ำมันและก๊าซ (และพบว่ามีการใช้งานมากกว่าในวิศวกรรมเครื่องกล) มีเพียง Statoil (Equinor) เท่านั้นที่ติดใจเขาทั่วนอร์เวย์ ระบบนิเวศ. คนอื่นพยายามทำสิ่งของตัวเอง ตัวอย่างเช่น ตามข่าวลือ กระทรวงพลังงานในประเทศตั้งใจที่จะสร้าง "แบบจำลองทางภววิทยาเชิงแนวคิดของเชื้อเพลิงและพลังงานที่ซับซ้อน" ซึ่งคล้ายกับที่ดูเหมือนจะเป็น สร้างขึ้นสำหรับอุตสาหกรรมพลังงานไฟฟ้า.

• สถาบันการเงิน (แม้ XBRL จะถูกมองว่าเป็นลูกผสมของ SDMX และ RDF Data Cube ontology)

เฉพาะที่

LinkedIn เมื่อต้นปีส่งสแปมผู้เขียนด้วยตำแหน่งงานว่างจากยักษ์ใหญ่เกือบทั้งหมดของอุตสาหกรรมการเงิน ซึ่งเขารู้จักจากซีรีส์โทรทัศน์เรื่อง Suits: Goldman Sachs, JPMorgan Chase และ/หรือ Morgan Stanley, Wells Fargo, SWIFT/Visa/ Mastercard, Bank of America, Citigroup, the Fed, Deutsche Bank… ทุกคนคงมองหาคนที่จะส่งไป การประชุมกราฟความรู้. มีเพียงไม่กี่คนที่ค้นพบ: สถาบันการเงินครอบครองทุกอย่าง เช้าวันแรก.

ใน HeadHunter สิ่งที่น่าสนใจพบเฉพาะจาก Sberbank ก็คือ "พื้นที่จัดเก็บ EAV ที่มีโมเดลข้อมูลคล้าย RDF"

อาจเป็นไปได้ว่าความแตกต่างในระดับความรักสำหรับเทคโนโลยีที่สอดคล้องกันของสถาบันการเงินในประเทศและตะวันตกนั้นเกิดจากลักษณะข้ามชาติของกิจกรรมหลัง เห็นได้ชัดว่าการผสานรวมข้ามพรมแดนของรัฐต้องการโซลูชันเชิงองค์กรและด้านเทคนิคที่แตกต่างกันในเชิงคุณภาพ

• ระบบคำถาม-คำตอบที่มีแอปพลิเคชันเชิงพาณิชย์ (IBM Watson, Apple Siri, Google Knowledge Graph);

เฉพาะที่

อย่างไรก็ตาม ผู้สร้าง Siri, Thomas Gruber เป็นผู้เขียนคำนิยามของ ontology (ในแง่ไอที) ว่าเป็น "ข้อกำหนดการกำหนดแนวคิด" ในความคิดของฉันการจัดเรียงคำใหม่ในคำจำกัดความนี้ไม่ได้เปลี่ยนความหมายซึ่งอาจบ่งบอกว่าไม่มีอยู่

• การเผยแพร่ข้อมูลที่มีโครงสร้าง (ด้วยเหตุผลที่ดีสิ่งนี้สามารถนำมาประกอบกับ Linked Open Data)

เฉพาะที่

แฟนตัวยงของ Linked Data คือ GLAM: แกลเลอรี ห้องสมุด หอจดหมายเหตุ และพิพิธภัณฑ์ พอเพียงที่จะกล่าวที่นี่ว่าเพื่อแทนที่ MARC21 หอสมุดแห่งชาติกำลังส่งเสริม บิบเฟรมซึ่ง เป็นรากฐานสำหรับอนาคตของคำอธิบายบรรณานุกรม และแน่นอนว่าขึ้นอยู่กับ RDF

วิกิสนเทศมักถูกอ้างถึงเป็นตัวอย่างของโครงการที่ประสบความสำเร็จในด้านข้อมูลเปิดที่เชื่อมโยง ซึ่งเป็นวิกิพีเดียเวอร์ชันที่เครื่องอ่านได้ ซึ่งเนื้อหาตรงกันข้ามกับ DBPedia ไม่ได้สร้างโดยการนำเข้าบทความจากกล่องข้อมูล แต่เป็น สร้างด้วยตนเองไม่มากก็น้อย (และต่อมากลายเป็นแหล่งข้อมูลสำหรับกล่องข้อมูลเดียวกัน)

แนะนำให้รีวิวด้วย รายการ ผู้ใช้พื้นที่เก็บข้อมูล Stardog RDF บนเว็บไซต์ Stardog ในส่วน "ลูกค้า"

เป็นไปได้ว่าใน Gartner "กระแสโฆษณาสำหรับเทคโนโลยีเกิดใหม่" 2016 "การจัดการอนุกรมวิธานองค์กรและออนโทโลจี" ถูกวางไว้กลางหุบเขาแห่งความผิดหวังพร้อมกับโอกาสที่จะไปถึง

การเชื่อมต่อข้อมูลองค์กร

คำทำนาย คำทำนาย คำทำนาย...

จากความสนใจในอดีต ฉันได้สรุปการคาดการณ์ของ Gartner ในปีต่างๆ สำหรับเทคโนโลยีที่เราสนใจในตารางด้านล่าง

ปี	เทคโนโลยี	รายงาน	ตำแหน่ง	ปีสู่ที่ราบสูง
2001	เว็บความหมาย	เทคโนโลยีใหม่ ๆ	ทริกเกอร์นวัตกรรม	5-10
2006	เว็บความหมายองค์กร	เทคโนโลยีใหม่ ๆ	จุดสูงสุดของความคาดหวังที่สูงเกินจริง	5-10
2012	เว็บความหมาย	ข้อมูลขนาดใหญ่	จุดสูงสุดของความคาดหวังที่สูงเกินจริง	> 10
2015	ข้อมูลที่เชื่อมโยง	การวิเคราะห์ขั้นสูงและวิทยาศาสตร์ข้อมูล	รางแห่งความผิดหวัง	5-10
2016	การจัดการอภิปรัชญาองค์กร	เทคโนโลยีใหม่ ๆ	รางแห่งความผิดหวัง	> 10
2018	กราฟความรู้	เทคโนโลยีใหม่ ๆ	ทริกเกอร์นวัตกรรม	5-10

แต่เข้ามาแล้ว "ไฮป์ ไซเคิล..." 2018 แนวโน้มขาขึ้นอื่นปรากฏขึ้น - กราฟความรู้ การเกิดใหม่เกิดขึ้น: กราฟ DBMS ซึ่งความสนใจของผู้ใช้และกองกำลังของนักพัฒนาเปลี่ยนไปภายใต้อิทธิพลของคำขอของอดีตและนิสัยของหลังเริ่มได้รับรูปทรงและตำแหน่งของ คู่แข่งรุ่นก่อนของพวกเขา

เกือบทุกกราฟในปัจจุบัน DBMS อ้างว่าเป็นแพลตฟอร์มที่เหมาะสมสำหรับการสร้าง "กราฟความรู้" ขององค์กร ("ข้อมูลที่เชื่อมโยง" บางครั้งถูกแทนที่ด้วย "ข้อมูลที่เชื่อมต่อ") แต่การอ้างสิทธิ์ดังกล่าวมีเหตุผลเพียงใด

ฐานข้อมูลกราฟยังคงเป็น asemantic ข้อมูลใน DBMS กราฟยังคงเป็นไซโลข้อมูลเดียวกัน ตัวระบุสตริงแทน URI ทำให้งานของการรวม DBMS ของกราฟสองรายการยังคงเป็นงานการรวมเดียวกัน ในขณะที่การรวมที่เก็บ RDF สองแห่งมักจะเป็นเรื่องของการรวมสองกราฟ RDF อีกแง่มุมหนึ่งของความไม่สัมพันธ์กันคือการไม่สะท้อนของโมเดลกราฟ LPG ซึ่งทำให้การจัดการข้อมูลเมตาโดยใช้แพลตฟอร์มเดียวกันทำได้ยาก

สุดท้าย DBMS แบบกราฟไม่มีเครื่องมืออนุมานหรือเครื่องมือกฎ ผลลัพธ์ของเอ็นจิ้นดังกล่าวสามารถทำซ้ำได้โดยการสืบค้นที่ซับซ้อน แต่สิ่งนี้เป็นไปได้แม้ใน SQL

อย่างไรก็ตาม คลัง RDF ชั้นนำไม่มีปัญหาในการรองรับรุ่น LPG แนวทางที่มั่นคงที่สุดคือแนวทางที่เสนอในคราวเดียวใน Blazegraph: โมเดล RDF* ซึ่งรวม RDF และ LPG

ขึ้น

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับการรองรับรุ่น LPG โดยที่เก็บ RDF ได้ในบทความก่อนหน้าเกี่ยวกับ Habré: "เกิดอะไรขึ้นกับที่เก็บ RDF ในตอนนี้". เกี่ยวกับกราฟความรู้และโครงสร้างข้อมูล ฉันหวังว่าวันหนึ่งจะมีการเขียนบทความแยกต่างหาก ส่วนสุดท้ายอย่างที่เข้าใจง่าย เขียนขึ้นอย่างเร่งรีบ อย่างไรก็ตาม หกเดือนต่อมา แนวคิดเหล่านี้ก็ยังไม่ชัดเจนมากนัก

วรรณกรรม

1. Halpin, H. , Monnin, A. (eds.) (2014). วิศวกรรมปรัชญา: สู่ปรัชญาของเว็บ
2. Allemang, D., Hendler, J. (2011) Semantic Web for the Working Ontologist (ฉบับที่ 2)
3. Staab, S., Studer, R. (eds.) (2009) Handbook on Ontology (ฉบับที่ 2)
4. ไม้, D. (เอ็ด). (2011) การเชื่อมโยงข้อมูลองค์กร
5. Keet, M. (2018) วิศวกรรมภววิทยาเบื้องต้น

ที่มา: will.com