Semantic Web ແລະຂໍ້ມູນເຊື່ອມຕໍ່. ການແກ້ໄຂແລະການເພີ່ມເຕີມ

ຂ້າພະ​ເຈົ້າຂໍ​ນຳ​ສະ​ເໜີ​ໃຫ້​ປະຊາຊົນ​ເຫັນ​ສ່ວນ​ໜຶ່ງ​ຂອງ​ປຶ້ມ​ທີ່​ພິມ​ຈຳໜ່າຍ​ເມື່ອ​ບໍ່​ດົນ​ມາ​ນີ້:

ການສ້າງແບບຈໍາລອງ ontological ຂອງວິສາຫະກິດ: ວິທີການແລະເຕັກໂນໂລຢີ [ຂໍ້ຄວາມ]: monograph / [S. V. Gorshkov, S. S. Kralin, O. I. Mushtak ແລະອື່ນໆ; ບັນນາທິການບໍລິຫານ S.V. Gorshkov]. - Ekaterinburg: Ural University Publishing House, 2019. - 234 p.: ill., table; 20 ຊຕມ - ຜູ້ຂຽນ. ຊີ້ບອກຢູ່ດ້ານຫຼັງ. ກັບ. — ບັນ​ນາ​ນຸ​ກົມ​ ໃນຕອນທ້າຍຂອງ ch. — ISBN 978-5-7996-2580-1: 200 ສະບັບ.

ຈຸດ​ປະ​ສົງ​ຂອງ​ການ​ປະ​ກອບ​ສ່ວນ​ນີ້​ກ່ຽວ​ກັບ​ການ Habre ແມ່ນ​ສີ່​:

• ມັນຄົງຈະບໍ່ເປັນໄປໄດ້ວ່າໃຜຈະສາມາດຖືປື້ມນີ້ຢູ່ໃນມືຂອງເຂົາເຈົ້າຖ້າລາວບໍ່ແມ່ນລູກຄ້າຂອງຜູ້ທີ່ນັບຖື SergeIndex; ມັນແນ່ນອນບໍ່ໄດ້ຢູ່ໃນການຂາຍ.
• ການແກ້ໄຂໄດ້ຖືກເຮັດໃຫ້ຂໍ້ຄວາມ (ພວກເຂົາບໍ່ໄດ້ເນັ້ນໃສ່ຂ້າງລຸ່ມນີ້) ແລະການເພີ່ມເຕີມໄດ້ຖືກເຮັດໃຫ້ບໍ່ເຫມາະສົມກັບຮູບແບບຂອງ monograph ທີ່ພິມອອກ: ບັນທຶກຫົວຂໍ້ (ພາຍໃຕ້ spoilers) ແລະ hyperlinks.
• ຂ້ອຍ​ຢາກ ເກັບກໍາຄໍາຖາມແລະຄໍາເຫັນ, ເພື່ອເອົາພວກມັນເຂົ້າໄປໃນບັນຊີໃນເວລາທີ່ລວມເອົາຂໍ້ຄວາມນີ້ໃນຮູບແບບທີ່ປັບປຸງໃຫມ່ໃນສິ່ງພິມອື່ນໆ.
• ຜູ້ຕິດຕາມ Semantic Web ແລະ Linked Data ຫຼາຍຄົນຍັງເຊື່ອວ່າວົງຂອງພວກເຂົາແຄບ, ສ່ວນໃຫຍ່ແມ່ນຍ້ອນວ່າປະຊາຊົນທົ່ວໄປຍັງບໍ່ທັນໄດ້ຮັບການອະທິບາຍຢ່າງຖືກຕ້ອງວ່າມັນເປັນສິ່ງທີ່ດີທີ່ຈະເປັນຜູ້ຍຶດຫມັ້ນຂອງ Semantic Web ແລະ Linked Data. ຜູ້ຂຽນຂອງຊິ້ນ, ເຖິງແມ່ນວ່າລາວຢູ່ໃນວົງການນີ້, ບໍ່ຖືຄວາມຄິດເຫັນນີ້, ແຕ່ຢ່າງໃດກໍ່ຕາມ, ຖືວ່າຕົນເອງມີພັນທະທີ່ຈະພະຍາຍາມອີກ.

ດັ່ງ​ນັ້ນ

Web Semantic

ວິວັດທະນາການຂອງອິນເຕີເນັດສາມາດສະແດງໄດ້ດັ່ງລຸ່ມນີ້ (ຫຼືສົນທະນາກ່ຽວກັບພາກສ່ວນຂອງມັນທີ່ຖືກສ້າງຕັ້ງຂຶ້ນຕາມລໍາດັບທີ່ລະບຸໄວ້ຂ້າງລຸ່ມນີ້):

1. ເອກະສານໃນອິນເຕີເນັດ. ເຕັກໂນໂລຢີທີ່ສໍາຄັນ - Gopher, FTP, ແລະອື່ນໆ.
   ອິນເຕີເນັດແມ່ນເຄືອຂ່າຍທົ່ວໂລກສໍາລັບການແລກປ່ຽນຊັບພະຍາກອນທ້ອງຖິ່ນ.
2. ເອກະສານທາງອິນເຕີເນັດ. ເຕັກໂນໂລຢີທີ່ສໍາຄັນແມ່ນ HTML ແລະ HTTP.
   ລັກສະນະຂອງຊັບພະຍາກອນທີ່ເປີດເຜີຍໃຊ້ເວລາເຂົ້າໄປໃນບັນຊີລັກສະນະຂອງອຸປະກອນການຖ່າຍທອດຂອງພວກເຂົາ.
3. ຂໍ້ມູນອິນເຕີເນັດ. ເຕັກໂນໂລຢີທີ່ສໍາຄັນ - REST ແລະ SOAP API, XHR, ແລະອື່ນໆ.
   ຍຸກຂອງການນໍາໃຊ້ອິນເຕີເນັດ, ບໍ່ພຽງແຕ່ປະຊາຊົນກາຍເປັນຜູ້ບໍລິໂພກຂອງຊັບພະຍາກອນ.
4. ຂໍ້ມູນອິນເຕີເນັດ. ເຕັກໂນໂລຢີທີ່ສໍາຄັນແມ່ນເຕັກໂນໂລຢີຂໍ້ມູນເຊື່ອມຕໍ່.
   ຂັ້ນຕອນທີສີ່ນີ້, ຄາດຄະເນໂດຍ Berners-Lee, ຜູ້ສ້າງເຕັກໂນໂລຢີຫຼັກທີສອງແລະຜູ້ອໍານວຍການ W3C, ເອີ້ນວ່າ Semantic Web; ເທກໂນໂລຍີຂໍ້ມູນເຊື່ອມໂຍງຖືກອອກແບບເພື່ອເຮັດໃຫ້ຂໍ້ມູນຢູ່ໃນເວັບບໍ່ພຽງແຕ່ສາມາດອ່ານໄດ້ດ້ວຍເຄື່ອງ, ແຕ່ຍັງ "ເຂົ້າໃຈເຄື່ອງຈັກ."

ຈາກສິ່ງທີ່ຕໍ່ໄປນີ້, ຜູ້ອ່ານຈະເຂົ້າໃຈການຕອບໂຕ້ລະຫວ່າງແນວຄວາມຄິດທີ່ສໍາຄັນຂອງໄລຍະທີສອງແລະສີ່:

• URLs ແມ່ນຄ້າຍຄືກັນກັບ URIs,
• ການປຽບທຽບຂອງ HTML ແມ່ນ RDF,
• hyperlinks HTML ແມ່ນຄ້າຍຄືກັນກັບການປະກົດ URI ໃນເອກະສານ RDF.

ເວັບໄຊຕ໌ Semantic ແມ່ນມີວິໄສທັດທີ່ເປັນລະບົບຂອງອະນາຄົດຂອງອິນເຕີເນັດຫຼາຍກ່ວາແນວໂນ້ມທີ່ມີລັກສະນະສະເພາະຫຼື lobbied, ເຖິງແມ່ນວ່າມັນສາມາດເອົາສິ່ງເຫຼົ່ານີ້ເຂົ້າໃນບັນຊີ. ຕົວຢ່າງ, ລັກສະນະທີ່ສໍາຄັນຂອງສິ່ງທີ່ເອີ້ນວ່າ Web 2.0 ແມ່ນຖືວ່າເປັນ "ເນື້ອຫາທີ່ສ້າງໂດຍຜູ້ໃຊ້." ໂດຍສະເພາະ, ຄໍາແນະນໍາ W3C ໄດ້ຖືກຮຽກຮ້ອງໃຫ້ພິຈາລະນາ "Web Annotation Ontology"ແລະການປະຕິບັດດັ່ງກ່າວ Solid.

ເວັບໄຊຕ໌ Semantic ຕາຍບໍ?

ຖ້າທ່ານປະຕິເສດ ຄວາມຄາດຫວັງທີ່ບໍ່ເປັນຈິງ, ສະຖານະການກັບເວັບ semantic ແມ່ນປະມານຄືກັນກັບຄອມມິວນິດໃນຊ່ວງເວລາຂອງສັງຄົມນິຍົມທີ່ພັດທະນາ (ແລະວ່າຄວາມສັດຊື່ຕໍ່ເງື່ອນໄຂເງື່ອນໄຂຂອງ Ilyich ແມ່ນສັງເກດເຫັນ, ໃຫ້ທຸກຄົນຕັດສິນໃຈດ້ວຍຕົນເອງ). ເຄື່ອງ​ມື​ຄົ້ນ​ຫາ ຂ້ອນຂ້າງສົບຜົນສໍາເລັດ ບັງຄັບເວັບໄຊທ໌ໃຫ້ໃຊ້ RDFa ແລະ JSON-LD ແລະຕົວເອງໃຊ້ເຕັກໂນໂລຢີທີ່ກ່ຽວຂ້ອງກັບສິ່ງທີ່ອະທິບາຍຂ້າງລຸ່ມນີ້ (Google Knowledge Graph, Bing Knowledge Graph).

ໂດຍທົ່ວໄປແລ້ວ, ຜູ້ຂຽນບໍ່ສາມາດເວົ້າໄດ້ວ່າສິ່ງທີ່ປ້ອງກັນການແຜ່ກະຈາຍຫຼາຍກວ່າເກົ່າ, ແຕ່ລາວສາມາດເວົ້າບົນພື້ນຖານປະສົບການສ່ວນຕົວ. ມີບັນຫາທີ່ສາມາດແກ້ໄຂໄດ້ "ນອກກ່ອງ" ໃນເງື່ອນໄຂຂອງການກະທໍາຜິດ SW, ເຖິງແມ່ນວ່າພວກມັນບໍ່ແຜ່ຫຼາຍ. ດັ່ງນັ້ນ, ຜູ້ທີ່ປະເຊີນຫນ້າກັບວຽກງານເຫຼົ່ານີ້ບໍ່ມີວິທີການບີບບັງຄັບຕໍ່ຜູ້ທີ່ສາມາດສະຫນອງການແກ້ໄຂໄດ້, ໃນຂະນະທີ່ການສະຫນອງການແກ້ໄຂເອກະລາດໃນອະດີດແມ່ນກົງກັນຂ້າມກັບຮູບແບບທຸລະກິດຂອງພວກເຂົາ. ດັ່ງນັ້ນພວກເຮົາສືບຕໍ່ວິເຄາະ HTML ແລະກາວ APIs ຕ່າງໆຮ່ວມກັນ, ເຊິ່ງກັນແລະກັນ.

ຢ່າງໃດກໍ່ຕາມ, ເທກໂນໂລຍີ Linked Data ໄດ້ແຜ່ຂະຫຍາຍອອກໄປນອກເວັບທົ່ວໄປ; ໃນຄວາມເປັນຈິງ, ປື້ມແມ່ນອຸທິດຕົນເພື່ອຄໍາຮ້ອງສະຫມັກເຫຼົ່ານີ້. ໃນປັດຈຸບັນ, ຊຸມຊົນຂໍ້ມູນເຊື່ອມໂຍງຄາດວ່າເຕັກໂນໂລຢີເຫຼົ່ານີ້ຈະແຜ່ຂະຫຍາຍຫຼາຍກວ່າເກົ່າຍ້ອນການບັນທຶກຂອງ Gartner (ຫຼືການປະກາດ, ຕາມທີ່ທ່ານຕ້ອງການ) ຂອງແນວໂນ້ມເຊັ່ນ: ຕາຕະລາງຄວາມຮູ້ и ຜ້າຂໍ້ມູນ. ຂ້າພະເຈົ້າຢາກເຊື່ອວ່າມັນຈະບໍ່ເປັນການປະຕິບັດ "ລົດຖີບ" ຂອງແນວຄວາມຄິດເຫຼົ່ານີ້ທີ່ຈະປະສົບຜົນສໍາເລັດ, ແຕ່ສິ່ງທີ່ກ່ຽວຂ້ອງກັບມາດຕະຖານ W3C ທີ່ໄດ້ປຶກສາຫາລືຂ້າງລຸ່ມນີ້.

ຂໍ້ມູນເຊື່ອມຕໍ່

Berners-Lee ກໍານົດການເຊື່ອມຕໍ່ຂໍ້ມູນເປັນເວັບ semantic "ເຮັດຖືກຕ້ອງ": ຊຸດຂອງວິທີການແລະເຕັກໂນໂລຢີທີ່ອະນຸຍາດໃຫ້ມັນບັນລຸເປົ້າຫມາຍສູງສຸດ. ຫຼັກການພື້ນຖານຂອງ Linked Data Berners-Lee ເນັ້ນໃສ່ ຕໍ່ໄປນີ້.

ຫຼັກການ 1. ການນໍາໃຊ້ URIs ເພື່ອຕັ້ງຊື່ຫນ່ວຍງານ.

URIs ແມ່ນຕົວລະບຸນິຕິບຸກຄົນທົ່ວໂລກເຊິ່ງກົງກັນຂ້າມກັບຕົວລະບຸສະຕຣິງທ້ອງຖິ່ນສຳລັບລາຍການ. ຫຼັງຈາກນັ້ນ, ຫຼັກການນີ້ໄດ້ຖືກສະແດງອອກທີ່ດີທີ່ສຸດໃນ Google Knowledge Graph slogan “ສິ່ງ, ບໍ່ແມ່ນສາຍ".

ຫຼັກການ 2. ການນໍາໃຊ້ URIs ໃນໂຄງການ HTTP ເພື່ອໃຫ້ພວກເຂົາສາມາດຖືກຍົກເລີກການອ້າງອີງ.

ໂດຍອ້າງອີງໃສ່ URI, ມັນຄວນຈະເປັນໄປໄດ້ທີ່ຈະໄດ້ຮັບຕົວຊີ້ບອກທີ່ຢູ່ເບື້ອງຫຼັງຕົວຊີ້ບອກນັ້ນ (ການປຽບທຽບກັບຊື່ຂອງຜູ້ປະຕິບັດການ "ແມ່ນຈະແຈ້ງຢູ່ທີ່ນີ້).*"ໃນ C); ຫຼາຍທີ່ຊັດເຈນ, ເພື່ອໃຫ້ໄດ້ຮັບການເປັນຕົວແທນບາງຢ່າງຂອງຄວາມຫມາຍນີ້ - ຂຶ້ນກັບມູນຄ່າຂອງ HTTP header Accept:. ບາງທີ, ດ້ວຍການມາຮອດຂອງຍຸກ AR / VR, ມັນເປັນໄປໄດ້ທີ່ຈະໄດ້ຮັບຊັບພະຍາກອນຂອງມັນເອງ, ແຕ່ສໍາລັບໃນປັດຈຸບັນ, ສ່ວນຫຼາຍອາດຈະເປັນເອກະສານ RDF, ເຊິ່ງເປັນຜົນມາຈາກການປະຕິບັດການສອບຖາມ SPARQL. DESCRIBE.

ຫຼັກການ 3. ການນໍາໃຊ້ມາດຕະຖານ W3C - ຕົ້ນຕໍແມ່ນ RDF(S) ແລະ SPARQL - ໂດຍສະເພາະໃນເວລາທີ່ອ້າງອີງ URIs.

ເຫຼົ່ານີ້ "ຊັ້ນ" ສ່ວນບຸກຄົນຂອງ stacked ເຕັກໂນໂລຊີຂໍ້ມູນ, ທີ່ເອີ້ນກັນວ່າ Semantic Web Layer Cake, ຈະໄດ້ຮັບການອະທິບາຍຂ້າງລຸ່ມນີ້.

ຫຼັກການ 4. ການ​ນໍາ​ໃຊ້​ການ​ອ້າງ​ອີງ URIs ອື່ນໆ​ໃນ​ເວ​ລາ​ທີ່​ອະ​ທິ​ບາຍ​ຫົວ​ຫນ່ວຍ​.

RDF ອະນຸຍາດໃຫ້ທ່ານຈໍາກັດຕົວເອງກັບຄໍາບັນຍາຍຂອງຊັບພະຍາກອນໃນພາສາທໍາມະຊາດ, ແລະຫຼັກການທີສີ່ຮຽກຮ້ອງໃຫ້ບໍ່ເຮັດສິ່ງນີ້. ຖ້າຫຼັກການທໍາອິດຖືກສັງເກດເຫັນທົ່ວໄປ, ມັນເປັນໄປໄດ້ໃນເວລາທີ່ອະທິບາຍຊັບພະຍາກອນເພື່ອອ້າງອີງເຖິງຄົນອື່ນ, ລວມທັງ "ຕ່າງປະເທດ", ເຊິ່ງແມ່ນເຫດຜົນທີ່ວ່າຂໍ້ມູນຖືກເອີ້ນວ່າການເຊື່ອມໂຍງ. ໃນຄວາມເປັນຈິງ, ມັນເກືອບບໍ່ສາມາດຫຼີກເວັ້ນໄດ້ທີ່ຈະໃຊ້ URIs ທີ່ມີຊື່ໃນຄໍາສັບ RDFS.

RDF

RDF (ໂຄງຮ່າງການອະທິບາຍຊັບພະຍາກອນ) ແມ່ນເປັນທາງການເພື່ອອະທິບາຍເຖິງຫົວໜ່ວຍທີ່ກ່ຽວຂ້ອງ.

ຄໍາຖະແຫຼງຂອງປະເພດ "ວິຊາ-predicate-object", ເອີ້ນວ່າ triplets, ແມ່ນເຮັດກ່ຽວກັບຫນ່ວຍງານແລະຄວາມສໍາພັນຂອງເຂົາເຈົ້າ. ໃນກໍລະນີທີ່ງ່າຍທີ່ສຸດ, ຫົວຂໍ້, predicate, ແລະວັດຖຸແມ່ນ URI ທັງຫມົດ. URI ດຽວກັນສາມາດຢູ່ໃນຕໍາແຫນ່ງທີ່ແຕກຕ່າງກັນໃນ triplets ທີ່ແຕກຕ່າງກັນ: ເປັນຫົວຂໍ້, predicate, ແລະວັດຖຸ; ດັ່ງນັ້ນ, triplets ປະກອບເປັນປະເພດຂອງກາຟທີ່ເອີ້ນວ່າ RDF graph.

ວິຊາແລະວັດຖຸສາມາດບໍ່ພຽງແຕ່ URIs, ແຕ່ຍັງເອີ້ນວ່າ nodes ຫວ່າງເປົ່າ, ແລະວັດຖຸຍັງສາມາດເປັນ ຕົວໜັງສື. ຕົວຫນັງສືແມ່ນຕົວຢ່າງຂອງປະເພດເບື້ອງຕົ້ນທີ່ປະກອບດ້ວຍການສະແດງຕົວຫນັງສືແລະການຊີ້ບອກປະເພດ.

ຕົວຢ່າງຂອງການຂຽນຕົວຫນັງສື (ໃນ syntax Turtle, ເພີ່ມເຕີມກ່ຽວກັບມັນຂ້າງລຸ່ມນີ້): "5.0"^^xsd:float и "five"^^xsd:string. ຕົວອັກສອນທີ່ມີປະເພດ rdf:langString ຍັງສາມາດຕິດຕັ້ງປ້າຍພາສາໄດ້; ໃນ Turtle ມັນຖືກຂຽນເຊັ່ນນີ້: "five"@en и "пять"@ru.

nodes ຫວ່າງເປົ່າແມ່ນຊັບພະຍາກອນ "ບໍ່ເປີດເຜີຍຊື່" ໂດຍບໍ່ມີການລະບຸທົ່ວໂລກ, ກ່ຽວກັບວ່າຄໍາຖະແຫຼງທີ່ສາມາດເຮັດໄດ້, ແນວໃດກໍ່ຕາມ; ປະເພດຂອງຕົວແປທີ່ມີຢູ່ແລ້ວ.

ດັ່ງນັ້ນ (ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນຈຸດທັງຫມົດຂອງ RDF):

• ຫົວຂໍ້ແມ່ນ URI ຫຼື node ຫວ່າງເປົ່າ,
• ການຄາດຄະເນແມ່ນ URI,
• ວັດຖຸແມ່ນ URI, node ຫວ່າງເປົ່າ, ຫຼືຕົວຫນັງສື.

ເປັນຫຍັງ predicates ບໍ່ສາມາດເປັນ nodes ຫວ່າງເປົ່າ?

ເຫດຜົນທີ່ເປັນໄປໄດ້ແມ່ນຄວາມປາຖະຫນາທີ່ຈະເຂົ້າໃຈຢ່າງເປັນທາງການແລະແປ triplet ເຂົ້າໄປໃນພາສາຂອງເຫດຜົນທໍາອິດ predicate. s p o ຄ້າຍຄືບາງສິ່ງບາງຢ່າງເຊັ່ນ: ບ່ອນທີ່ - ຄາດ​ຄະ​ເນ​, и - ຄົງທີ່. ຮ່ອງຮອຍຂອງຄວາມເຂົ້າໃຈນີ້ແມ່ນຢູ່ໃນເອກະສານ "LBase: Semantics ສໍາລັບພາສາຂອງ Semantic Web", ເຊິ່ງມີສະຖານະພາບຂອງບັນທຶກຂອງກຸ່ມເຮັດວຽກ W3C. ດ້ວຍຄວາມເຂົ້າໃຈນີ້, triplet s p []ບ່ອນທີ່ [] - node ເປົ່າ, ຈະຖືກແປເປັນ ບ່ອນທີ່ - ຕົວແປ, ແຕ່ວິທີການແປ s [] o? ເອກະສານທີ່ມີສະຖານະການແນະນໍາ W3C "RDF 1.1 ຄວາມໝາຍ” ສະເຫນີວິທີການແປພາສາອື່ນ, ແຕ່ຍັງບໍ່ໄດ້ພິຈາລະນາຄວາມເປັນໄປໄດ້ຂອງ predicates ເປັນ nodes ຫວ່າງເປົ່າ.

ຢ່າງໃດກໍຕາມ, Manu Sporni ອະນຸຍາດ.

RDF ແມ່ນຕົວແບບທີ່ບໍ່ມີຕົວຕົນ. RDF ສາມາດຂຽນໄດ້ (serialized) ໃນ syntax ຕ່າງໆ: RDF/XML, ເຕົ່າ (ມະນຸດສາມາດອ່ານໄດ້ຫຼາຍທີ່ສຸດ), JSON-LD, HDT (binary).

RDF ດຽວກັນສາມາດໄດ້ຮັບການ serialized ເປັນ RDF / XML ໃນວິທີທີ່ແຕກຕ່າງກັນ, ດັ່ງນັ້ນ, ສໍາລັບການຍົກຕົວຢ່າງ, ມັນບໍ່ມີຄວາມຫມາຍທີ່ຈະກວດສອບ XML ຜົນໄດ້ຮັບໂດຍໃຊ້ XSD ຫຼືພະຍາຍາມສະກັດຂໍ້ມູນໂດຍໃຊ້ XPath. ເຊັ່ນດຽວກັນ, JSON-LD ຄົງຈະບໍ່ຕອບສະໜອງຄວາມປາດຖະໜາຂອງນັກພັດທະນາ Javascript ໂດຍສະເລ່ຍທີ່ຈະເຮັດວຽກກັບ RDF ໂດຍໃຊ້ເຄື່ອງໝາຍຈຸດ ແລະວົງເລັບສີ່ຫຼ່ຽມຂອງ Javascript (ເຖິງແມ່ນວ່າ JSON-LD ເຄື່ອນຍ້າຍໄປໃນທິດທາງນັ້ນໂດຍສະເໜີກົນໄກ. ກອບ).

syntax ສ່ວນໃຫຍ່ສະເຫນີວິທີການຫຍໍ້ URIs ຍາວ. ຕົວຢ່າງ, ໂຄສະນາ @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 ເປັນຄຳອະທິບາຍ ແລະການສ້າງແບບຈຳລອງ, ແຕ່ບໍ່ແມ່ນພາສາທີ່ຈຳກັດ (ເຖິງແມ່ນຈະກຳນົດເປັນທາງການ ແລະ ໃບ ຄວາມເປັນໄປໄດ້ຂອງການນໍາໃຊ້ດັ່ງກ່າວ). ຄໍາວ່າ "Schema" ບໍ່ຄວນເຂົ້າໃຈໃນຄວາມຫມາຍດຽວກັນກັບຄໍາວ່າ "XML Schema". ຍົກ​ຕົວ​ຢ່າງ, :author rdfs:range foaf:Person ໝາຍ ຄວາມວ່າ rdf:type ມູນຄ່າຊັບສິນທັງຫມົດ :author - foaf:Person, ແຕ່ບໍ່ໄດ້ຫມາຍຄວາມວ່ານີ້ຄວນຈະເວົ້າລ່ວງຫນ້າ.

SPARQL

SPARQL (SPARQL Protocol ແລະ RDF Query Language) - ພາສາສໍາລັບການສອບຖາມຂໍ້ມູນ RDF. ໃນກໍລະນີທີ່ງ່າຍດາຍ, ການສອບຖາມ SPARQL ແມ່ນຊຸດຂອງຕົວຢ່າງທີ່ triplets ຂອງກາຟທີ່ຖືກສອບຖາມແມ່ນກົງກັນ. ຮູບແບບສາມາດມີຕົວແປໃນຫົວຂໍ້, predicate, ແລະຕໍາແຫນ່ງວັດຖຸ.

ການສອບຖາມຈະສົ່ງຄືນຄ່າຕົວແປດັ່ງກ່າວທີ່, ເມື່ອຖືກທົດແທນເຂົ້າໄປໃນຕົວຢ່າງ, ສາມາດສົ່ງຜົນໃຫ້ເສັ້ນຍ່ອຍຂອງກາຟ RDF ທີ່ຖືກສອບຖາມ (ຊຸດຍ່ອຍຂອງ triplets ຂອງມັນ). ຕົວແປຂອງຊື່ດຽວກັນໃນຕົວຢ່າງທີ່ແຕກຕ່າງກັນຂອງ triplets ຕ້ອງມີມູນຄ່າດຽວກັນ.

ຕົວຢ່າງ, ໃຫ້ຊຸດຂ້າງເທິງຂອງເຈັດ RDFS axioms, ຄໍາຖາມຕໍ່ໄປນີ້ຈະກັບຄືນມາ rdfs:domain и rdfs:range ເປັນຄຸນຄ່າ ?s и ?p ຕາມ ລຳ ດັບ:

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

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າ SPARQL ແມ່ນການປະກາດແລະບໍ່ແມ່ນພາສາສໍາລັບການອະທິບາຍເສັ້ນສະແດງເສັ້ນຜ່ານແດນ (ຢ່າງໃດກໍ່ຕາມ, ບາງບ່ອນເກັບມ້ຽນ RDF ສະເຫນີວິທີການປັບແຜນການປະຕິບັດການສອບຖາມ). ດັ່ງນັ້ນ, ບາງບັນຫາກາຟມາດຕະຖານ, ສໍາລັບການຍົກຕົວຢ່າງ, ການຊອກຫາເສັ້ນທາງທີ່ສັ້ນທີ່ສຸດ, ບໍ່ສາມາດແກ້ໄຂໄດ້ໃນ SPARQL, ລວມທັງການນໍາໃຊ້. ເສັ້ນທາງຊັບສິນ (ແຕ່, ອີກເທື່ອຫນຶ່ງ, repositories RDF ສ່ວນບຸກຄົນສະເຫນີການຂະຫຍາຍພິເສດເພື່ອແກ້ໄຂບັນຫາເຫຼົ່ານີ້).

SPARQL ບໍ່ໄດ້ແບ່ງປັນການສົມມຸດຕິຖານຂອງການເປີດກວ້າງຂອງໂລກແລະປະຕິບັດຕາມ "ການປະຕິເສດເປັນຄວາມລົ້ມເຫລວ", ໃນນັ້ນ. ເປັນໄປໄດ້ ການອອກແບບເຊັ່ນ: FILTER NOT EXISTS {…}. ການແຈກຢາຍຂໍ້ມູນຖືກພິຈາລະນາໂດຍໃຊ້ກົນໄກ ການສອບຖາມສະຫະພັນ.

ຈຸດເຂົ້າເຖິງ SPARQL - ເປັນບ່ອນເກັບຂໍ້ມູນ RDF ທີ່ສາມາດປະມວນຜົນການສອບຖາມ SPARQL - ບໍ່ມີການປຽບທຽບໂດຍກົງຈາກຂັ້ນຕອນທີສອງ (ເບິ່ງຈຸດເລີ່ມຕົ້ນຂອງວັກນີ້). ມັນສາມາດຖືກປຽບທຽບກັບຖານຂໍ້ມູນ, ໂດຍອີງໃສ່ເນື້ອໃນຂອງຫນ້າ HTML ທີ່ຖືກສ້າງຂຶ້ນ, ແຕ່ສາມາດເຂົ້າເຖິງພາຍນອກ. ຈຸດເຂົ້າເຖິງ SPARQL ແມ່ນຄ້າຍຄືກັນກັບຈຸດເຂົ້າເຖິງ API ຈາກຂັ້ນຕອນທີສາມ, ແຕ່ມີສອງຄວາມແຕກຕ່າງຕົ້ນຕໍ. ກ່ອນອື່ນ ໝົດ, ມັນເປັນໄປໄດ້ທີ່ຈະສົມທົບການສອບຖາມ "ປະລໍາມະນູ" ຫຼາຍໆຢ່າງເຂົ້າໄປໃນຫນຶ່ງ (ເຊິ່ງຖືວ່າເປັນລັກສະນະທີ່ສໍາຄັນຂອງ GraphQL), ແລະອັນທີສອງ, API ດັ່ງກ່າວແມ່ນເອກະສານດ້ວຍຕົນເອງຢ່າງສົມບູນ (ເຊິ່ງເປັນສິ່ງທີ່ HATEOAS ພະຍາຍາມບັນລຸ).

ຂໍ້ສັງເກດທາງການເມືອງ

RDF ແມ່ນວິທີການເຜີຍແຜ່ຂໍ້ມູນໃນເວັບ, ດັ່ງນັ້ນການເກັບຮັກສາ RDF ຄວນຖືວ່າເປັນເອກະສານ DBMS. ແທ້ຈິງແລ້ວ, ເນື່ອງຈາກວ່າ RDF ແມ່ນກາຟແລະບໍ່ແມ່ນຕົ້ນໄມ້, ພວກມັນຍັງກາຍເປັນກາຟ. ມັນເຮັດໃຫ້ປະລາດທີ່ມັນເຮັດວຽກອອກທັງຫມົດ. ໃຜຈະຄິດວ່າຈະມີຄົນສະຫລາດທີ່ຈະປະຕິບັດ nodes ເປົ່າ. Codd ຢູ່ທີ່ນີ້ ມັນບໍ່ໄດ້ຜົນ.

ຍັງມີວິທີການທີ່ມີລັກສະນະເຕັມທີ່ຫນ້ອຍໃນການຈັດຕັ້ງການເຂົ້າເຖິງຂໍ້ມູນ RDF, ສໍາລັບຕົວຢ່າງ, ຊິ້ນສ່ວນຂໍ້ມູນທີ່ເຊື່ອມໂຍງ (LDF) ແລະ ແພລະຕະຟອມຂໍ້ມູນເຊື່ອມຕໍ່ (LDP).

OWL

OWL (Web Ontology Language) - ເປັນທາງການເພື່ອສະແດງຄວາມຮູ້, ສະບັບ syntactic ຂອງເຫດຜົນຄໍາອະທິບາຍ (ຢູ່ທົ່ວທຸກແຫ່ງຂ້າງລຸ່ມນີ້ແມ່ນຖືກຕ້ອງກວ່າທີ່ຈະເວົ້າວ່າ OWL 2, ສະບັບທໍາອິດຂອງ OWL ແມ່ນອີງໃສ່ ).

ແນວຄວາມຄິດຂອງເຫດຜົນອະທິບາຍໃນ OWL ກົງກັບຫ້ອງຮຽນ, ພາລະບົດບາດກົງກັບຄຸນສົມບັດ, ບຸກຄົນຮັກສາຊື່ທີ່ຜ່ານມາຂອງເຂົາເຈົ້າ. Axioms ຍັງຖືກເອີ້ນວ່າ axioms.

ສໍາລັບຕົວຢ່າງ, ໃນອັນທີ່ເອີ້ນວ່າ Manchester syntax ສໍາລັບ OWL notation axiom ຮູ້ຈັກກັບພວກເຮົາແລ້ວ ຈະ​ໄດ້​ຮັບ​ການ​ຂຽນ​ດັ່ງ​ນີ້​:

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

ມີ syntaxes ອື່ນໆສໍາລັບການຂຽນ OWL, ເຊັ່ນ: syntax ທີ່ເປັນປະໂຫຍດ, ນໍາໃຊ້ໃນຂໍ້ກໍານົດຢ່າງເປັນທາງການ, ແລະ OWL/XML. ນອກຈາກນັ້ນ, OWL ສາມາດໄດ້ຮັບການ serialized ກັບ syntax RDF abstract ແລະຕື່ມອີກ - ໃນ syntax ສະເພາະໃດນຶ່ງ.

OWL ມີການພົວພັນຄູ່ກັບ RDF. ໃນອີກດ້ານຫນຶ່ງ, ມັນສາມາດຖືວ່າເປັນປະເພດຂອງວັດຈະນານຸກົມທີ່ຂະຫຍາຍ RDFS. ໃນທາງກົງກັນຂ້າມ, ມັນເປັນທາງການທີ່ມີອໍານາດຫຼາຍກວ່າທີ່ RDF ແມ່ນພຽງແຕ່ຮູບແບບ serialization. ບໍ່ແມ່ນໂຄງສ້າງ OWL ປະຖົມທັງໝົດສາມາດຂຽນໄດ້ໂດຍໃຊ້ RDF triplet ດຽວ.

ອີງຕາມຊຸດຍ່ອຍຂອງໂຄງສ້າງ OWL ຖືກອະນຸຍາດໃຫ້ນໍາໃຊ້, ພວກເຂົາເວົ້າເຖິງອັນທີ່ເອີ້ນວ່າ ໂປຣໄຟລ໌ OWL. ມາດຕະຖານແລະມີຊື່ສຽງຫຼາຍທີ່ສຸດແມ່ນ OWL EL, OWL RL ແລະ OWL QL. ການເລືອກໂປຣໄຟລ໌ສົ່ງຜົນກະທົບຕໍ່ຄວາມສັບສົນທາງຄອມພິວເຕີຂອງບັນຫາທົ່ວໄປ. ຊຸດທີ່ສົມບູນຂອງການກໍ່ສ້າງ OWL ທີ່ສອດຄ້ອງກັນ , ເອີ້ນວ່າ OWL DL. ບາງຄັ້ງພວກເຂົາຍັງເວົ້າກ່ຽວກັບ OWL Full, ເຊິ່ງການກໍ່ສ້າງຂອງ OWL ແມ່ນອະນຸຍາດໃຫ້ຖືກນໍາໃຊ້ກັບສິດເສລີພາບຢ່າງເຕັມທີ່ທີ່ມີຢູ່ໃນ RDF, ໂດຍບໍ່ມີຂໍ້ຈໍາກັດທາງດ້ານຄວາມຫມາຍແລະການຄິດໄລ່. . ຕົວຢ່າງ, ບາງສິ່ງບາງຢ່າງສາມາດເປັນທັງຫ້ອງຮຽນແລະຊັບສິນ. OWL Full ແມ່ນບໍ່ສາມາດຕັດສິນໄດ້.

ຫຼັກການສໍາຄັນສໍາລັບການຄັດຕິດຜົນສະທ້ອນໃນ OWL ແມ່ນການຮັບຮອງເອົາການສົມມຸດຕິຖານໂລກເປີດ. ໂອວາ) ແລະການປະຕິເສດການສົມມຸດຕິຖານຂອງຊື່ທີ່ເປັນເອກະລັກ (ສົມມຸດຕິຖານຊື່ເປັນເອກະລັກ, UNA). ຂ້າງລຸ່ມນີ້ພວກເຮົາຈະເບິ່ງບ່ອນທີ່ຫຼັກການເຫຼົ່ານີ້ສາມາດນໍາພາແລະແນະນໍາການກໍ່ສ້າງ OWL ບາງ.

ໃຫ້ ontology ມີຊິ້ນສ່ວນຕໍ່ໄປນີ້ (ໃນ syntax Manchester):

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

ມັນ​ຈະ​ຕິດ​ຕາມ​ທີ່​ໄດ້​ກ່າວ​ວ່າ​ໂຢ​ຮັນ​ມີ​ລູກ​ຫຼາຍ​ຄົນ​ບໍ? ການປະຕິເສດ UNA ຈະບັງຄັບໃຫ້ເຄື່ອງຈັກ inference ຕອບຄໍາຖາມນີ້ໃນທາງລົບ, ເພາະວ່າ Alice ແລະ Bob ອາດຈະເປັນຄົນດຽວກັນ. ເພື່ອໃຫ້ສິ່ງຕໍ່ໄປນີ້ເກີດຂຶ້ນ, ທ່ານຈະຕ້ອງເພີ່ມ axiom ຕໍ່ໄປນີ້:

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

ontology ນີ້ຈະບໍ່ສອດຄ່ອງ (ຊຶ່ງສາມາດຕີຄວາມຫມາຍຂອງຂໍ້ມູນທີ່ບໍ່ຖືກຕ້ອງ)? ການຍອມຮັບ OWA ຈະເຮັດໃຫ້ເຄື່ອງຈັກ inference ຕອບສະຫນອງໃນທາງລົບ: "ບ່ອນໃດບ່ອນຫນຶ່ງ" (ໃນ ontology ອື່ນ) ມັນອາດຈະເວົ້າໄດ້ວ່າ Carol ແມ່ນເດັກນ້ອຍຂອງ John.

ເພື່ອປະຕິເສດຄວາມເປັນໄປໄດ້ຂອງເລື່ອງນີ້, ໃຫ້ເພີ່ມຄວາມຈິງໃຫມ່ກ່ຽວກັບ John:

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

ເພື່ອຍົກເວັ້ນຮູບລັກສະນະຂອງເດັກນ້ອຍອື່ນໆ, ໃຫ້ເວົ້າວ່າຄຸນຄ່າທັງຫມົດຂອງຊັບສິນ "ການມີລູກ" ແມ່ນປະຊາຊົນ, ເຊິ່ງພວກເຮົາມີພຽງແຕ່ສີ່:

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

ໃນປັດຈຸບັນ ontology ຈະກາຍເປັນຄວາມຂັດແຍ້ງ, ເຊິ່ງເຄື່ອງຈັກ inference ຈະບໍ່ລົ້ມເຫລວທີ່ຈະລາຍງານ. ດ້ວຍຂໍ້ສຸດທ້າຍຂອງ axioms ທີ່ພວກເຮົາມີ, ໃນຄວາມຫມາຍ, "ປິດ" ໂລກ, ແລະສັງເກດເຫັນວ່າຄວາມເປັນໄປໄດ້ຂອງ John ການເປັນລູກຂອງລາວໄດ້ຖືກຍົກເວັ້ນແນວໃດ.

ການເຊື່ອມໂຍງຂໍ້ມູນວິສາຫະກິດ

ຊຸດຂໍ້ມູນການເຊື່ອມໂຍງຂອງວິທີການແລະເຕັກໂນໂລຢີແມ່ນມີຈຸດປະສົງເບື້ອງຕົ້ນສໍາລັບການເຜີຍແຜ່ຂໍ້ມູນໃນເວັບ. ການນໍາໃຊ້ຂອງພວກເຂົາໃນສະພາບແວດລ້ອມຂອງບໍລິສັດພາຍໃນປະເຊີນກັບຄວາມຫຍຸ້ງຍາກຈໍານວນຫນຶ່ງ.

ຕົວຢ່າງ, ໃນສະພາບແວດລ້ອມຂອງບໍລິສັດທີ່ປິດ, ອໍານາດຫັກຂອງ OWL ໂດຍອີງໃສ່ການຮັບຮອງເອົາ OWA ແລະການປະຕິເສດຂອງ UNA, ການຕັດສິນໃຈເນື່ອງຈາກລັກສະນະເປີດແລະແຈກຢາຍຂອງເວັບ, ແມ່ນອ່ອນແອເກີນໄປ. ແລະໃນທີ່ນີ້ວິທີແກ້ໄຂຕໍ່ໄປນີ້ແມ່ນເປັນໄປໄດ້.

• ມອບ OWL ດ້ວຍ semantics, ຫມາຍເຖິງການປະຖິ້ມ OWA ແລະການຮັບຮອງເອົາ UNA, ການປະຕິບັດເຄື່ອງຈັກຜົນຜະລິດທີ່ສອດຄ້ອງກັນ. - ຕາມເສັ້ນທາງນີ້ ກຳ ລັງຈະ ບ່ອນຈັດເກັບຂໍ້ມູນ Stardog RDF.
• ການປະຖິ້ມຄວາມສາມາດໃນການຫັກລົບຂອງ OWL ໃນເງື່ອນໄຂຂອງເຄື່ອງຈັກກົດລະບຽບ. - ສະ​ຫນັບ​ສະ​ຫນູນ Stardog​ SWRL; Jena ແລະ GraphDB ສະເຫນີ ເປັນເຈົ້າຂອງ ພາສາ ກົດລະບຽບ
• ການປະຕິເສດຄວາມສາມາດຫັກຂອງ OWL, ການນໍາໃຊ້ຫນຶ່ງຫຼືຊຸດຍ່ອຍອື່ນທີ່ໃກ້ຊິດກັບ RDFS ສໍາລັບການສ້າງແບບຈໍາລອງ. - ເບິ່ງເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ຂ້າງລຸ່ມນີ້.

ບັນຫາອີກປະການຫນຶ່ງແມ່ນຈຸດສຸມຫຼາຍກວ່າເກົ່າທີ່ໂລກຂອງບໍລິສັດອາດຈະມີບັນຫາກ່ຽວກັບຄຸນນະພາບຂໍ້ມູນແລະການຂາດເຄື່ອງມືການກວດສອບຂໍ້ມູນໃນ Linked Data stack. ຜົນ​ໄດ້​ຮັບ​ທີ່​ນີ້​ແມ່ນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​.

• ອີກເທື່ອຫນຶ່ງ, ໃຊ້ສໍາລັບການກວດສອບການກໍ່ສ້າງຂອງ OWL ກັບ semantics ໂລກປິດແລະຊື່ທີ່ເປັນເອກະລັກຖ້າຫາກວ່າເຄື່ອງຈັກ inference ທີ່ເຫມາະສົມສາມາດໃຊ້ໄດ້.
• ການນໍາໃຊ້ SHACL, ມາດຕະຖານຫຼັງຈາກບັນຊີລາຍຊື່ຂອງ Semantic Web Layer Cake layers ໄດ້ຖືກແກ້ໄຂ (ຢ່າງໃດກໍ່ຕາມ, ມັນຍັງສາມາດຖືກນໍາໃຊ້ເປັນເຄື່ອງຈັກກົດລະບຽບ), ຫຼື SheEx.
• ເຂົ້າໃຈວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນເຮັດໄດ້ໃນທີ່ສຸດດ້ວຍການສອບຖາມ SPARQL, ສ້າງກົນໄກການກວດສອບຂໍ້ມູນແບບງ່າຍໆຂອງທ່ານເອງໂດຍໃຊ້ພວກມັນ.

ຢ່າງໃດກໍ່ຕາມ, ເຖິງແມ່ນວ່າການປະຕິເສດຢ່າງສົມບູນຂອງຄວາມສາມາດຫັກລົບແລະເຄື່ອງມືການກວດສອບເຮັດໃຫ້ Linked Data stack ອອກຈາກການແຂ່ງຂັນໃນຫນ້າວຽກທີ່ຄ້າຍຄືກັນໃນພູມສັນຖານກັບເວັບເປີດແລະແຈກຢາຍ - in data integration tasks .

ຈະເປັນແນວໃດກ່ຽວກັບລະບົບຂໍ້ມູນຂ່າວສານວິສາຫະກິດປົກກະຕິ?

ນີ້ເປັນໄປໄດ້, ແຕ່ແນ່ນອນ, ທ່ານຄວນຮູ້ເຖິງບັນຫາທີ່ເຕັກໂນໂລຢີທີ່ສອດຄ້ອງກັນຈະຕ້ອງແກ້ໄຂ. ຂ້າພະເຈົ້າຈະອະທິບາຍຢູ່ທີ່ນີ້ຕິກິຣິຍາປົກກະຕິຂອງຜູ້ເຂົ້າຮ່ວມການພັດທະນາເພື່ອສະແດງໃຫ້ເຫັນສິ່ງທີ່ stack ເຕັກໂນໂລຊີນີ້ຄ້າຍຄືຈາກທັດສະນະຂອງ IT ທໍາມະດາ. ເຕືອນຂ້ອຍເລັກນ້ອຍກ່ຽວກັບຄໍາອຸປະມາຂອງຊ້າງ:

• ນັກວິເຄາະທຸລະກິດ: RDF ແມ່ນບາງສິ່ງບາງຢ່າງຄ້າຍຄືຕົວແບບຢ່າງມີເຫດຜົນທີ່ເກັບຮັກສາໄວ້ໂດຍກົງ.
• ນັກວິເຄາະລະບົບ: RDF ຄື EAV, ພຽງແຕ່ມີຊໍ່ຂອງດັດສະນີແລະພາສາສອບຖາມທີ່ສະດວກ.
• ນັກພັດທະນາ: ດີ, ນີ້ແມ່ນທັງຫມົດໃນຈິດໃຈຂອງແນວຄວາມຄິດຂອງຮູບແບບອຸດົມສົມບູນແລະລະຫັດຕ່ໍາ, ໄດ້ອ່ານ ບໍ່ດົນມານີ້ກ່ຽວກັບເລື່ອງນີ້.
• ຜູ້​ຈັດ​ການ​ໂຄງ​ການ: ແມ່ນແລ້ວມັນຄືກັນ ຍຸບ stack ໄດ້!

ການປະຕິບັດສະແດງໃຫ້ເຫັນວ່າ stack ຖືກນໍາໃຊ້ຫຼາຍທີ່ສຸດໃນວຽກງານທີ່ກ່ຽວຂ້ອງກັບການແຈກຢາຍແລະ heterogeneity ຂອງຂໍ້ມູນ, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນເວລາທີ່ການກໍ່ສ້າງລະບົບຫ້ອງຮຽນ MDM (Master Data Management) ຫຼື DWH (Data Warehouse) ລະບົບຊັ້ນຮຽນ. ບັນຫາດັ່ງກ່າວມີຢູ່ໃນອຸດສາຫະກໍາໃດກໍ່ຕາມ.

ໃນແງ່ຂອງຄໍາຮ້ອງສະຫມັກສະເພາະອຸດສາຫະກໍາ, ເຕັກໂນໂລຢີຂໍ້ມູນການເຊື່ອມໂຍງແມ່ນມີຄວາມນິຍົມຫຼາຍທີ່ສຸດໃນອຸດສາຫະກໍາຕໍ່ໄປນີ້.

• ເຕັກໂນໂລຢີດ້ານຊີວະວິທະຍາ (ບ່ອນທີ່ຄວາມນິຍົມຂອງພວກເຂົາເບິ່ງຄືວ່າມີຄວາມກ່ຽວຂ້ອງກັບຄວາມສັບສົນຂອງໂດເມນ);

ປະຈຸບັນ

ຫວ່າງ​ມໍ່ໆ​ມາ​ນີ້, “ຈຸດ​ເດືອດ​ຮ້ອນ” ​ໄດ້​ຈັດ​ກອງ​ປະຊຸມ​ໂດຍ​ສະມາຄົມ “ພື້ນຖານ​ຄວາມ​ຮູ້​ດ້ານ​ການ​ແພດ​ແຫ່ງ​ຊາດ”.ການປະສົມປະສານ ontologies. ຈາກທິດສະດີໄປສູ່ການປະຕິບັດຕົວຈິງ".

• ການ​ຜະ​ລິດ​ແລະ​ການ​ດໍາ​ເນີນ​ງານ​ຜະ​ລິດ​ຕະ​ພັນ​ສະ​ລັບ​ສັບ​ຊ້ອນ (ວິ​ສະ​ວະ​ກໍາ​ກົນ​ຈັກ​ຂະ​ຫນາດ​ໃຫຍ່​, ການ​ຜະ​ລິດ​ນ​້​ໍາ​ມັນ​ແລະ​ອາຍ​ແກ​ັ​ສ​; ສ່ວນ​ຫຼາຍ​ພວກ​ເຮົາ​ກໍາ​ລັງ​ເວົ້າ​ກ່ຽວ​ກັບ​ມາດ​ຕະ​ຖານ​ ISO 15926);

ປະຈຸບັນ

ທີ່ນີ້, ເຊັ່ນດຽວກັນ, ເຫດຜົນແມ່ນຄວາມສັບສົນຂອງຫົວຂໍ້ວິຊາ, ເມື່ອ, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນຂັ້ນຕອນຂອງນ້ໍາ, ຖ້າພວກເຮົາສົນທະນາກ່ຽວກັບອຸດສາຫະກໍານ້ໍາມັນແລະອາຍແກັສ, ບັນຊີງ່າຍດາຍຮຽກຮ້ອງໃຫ້ມີບາງຫນ້າທີ່ CAD.

ໃນປີ 2008, ເຫດການການຕິດຕັ້ງຕົວແທນ, ຈັດຕັ້ງໂດຍ Chevron, ໄດ້ຈັດຂຶ້ນ ກອງປະຊຸມ.

ISO 15926, ໃນທີ່ສຸດ, ເບິ່ງຄືວ່າມີຄວາມຫນັກຫນ່ວງຕໍ່ອຸດສາຫະກໍານ້ໍາມັນແລະອາຍແກັສ (ແລະບາງທີອາດມີການນໍາໃຊ້ຫຼາຍກວ່າເກົ່າໃນວິສະວະກໍາກົນຈັກ). ພຽງແຕ່ Statoil (Equinor) ໄດ້ຖືກຕິດພັນກັບມັນ; ໃນນໍເວ, ທັງຫມົດ ລະບົບນິເວດ. ຄົນອື່ນກໍາລັງພະຍາຍາມເຮັດສິ່ງຂອງຕົນເອງ. ສໍາລັບຕົວຢ່າງ, ອີງຕາມຂ່າວລື, ກະຊວງພະລັງງານພາຍໃນປະເທດຕັ້ງໃຈທີ່ຈະສ້າງ "ຮູບແບບ ontological ແນວຄວາມຄິດຂອງສະລັບສັບຊ້ອນນໍ້າມັນເຊື້ອໄຟແລະພະລັງງານ," ຄ້າຍຄືກັນ, ປາກົດຂື້ນ, ເພື່ອ. ສ້າງ​ສໍາ​ລັບ​ອຸດ​ສາ​ຫະ​ກໍາ​ພະ​ລັງ​ງານ​ໄຟ​ຟ້າ​.

• ອົງການຈັດຕັ້ງທາງດ້ານການເງິນ (ເຖິງແມ່ນວ່າ XBRL ສາມາດໄດ້ຮັບການພິຈາລະນາປະເພດຂອງການປະສົມຂອງ SDMX ແລະ RDF Data Cube ontology);

ປະຈຸບັນ

ໃນຕອນຕົ້ນຂອງປີ, LinkedIn ໄດ້ spammed ຜູ້ຂຽນຢ່າງຈິງຈັງກັບບ່ອນຫວ່າງຈາກເກືອບທັງຫມົດຍັກໃຫຍ່ຂອງອຸດສາຫະກໍາການເງິນ, ເຊິ່ງລາວຮູ້ຈາກຊຸດໂທລະທັດ "Force Majeure": Goldman Sachs, JPMorgan Chase ແລະ / ຫຼື Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, Fed, Deutsche Bank... ອາດຈະທຸກຄົນກຳລັງຊອກຫາຄົນທີ່ເຂົາເຈົ້າສາມາດສົ່ງຫາ ກອງປະຊຸມ Knowledge Graph. ຂ້ອນຂ້າງຈໍານວນຫນ້ອຍທີ່ຄຸ້ມຄອງເພື່ອຊອກຫາ: ອົງການຈັດຕັ້ງທາງດ້ານການເງິນໄດ້ເອົາທຸກສິ່ງທຸກຢ່າງ ຕອນເຊົ້າຂອງມື້ທໍາອິດ.

ໃນ HeadHunter, ມີພຽງແຕ່ Sberbank ເທົ່ານັ້ນທີ່ພົບສິ່ງທີ່ຫນ້າສົນໃຈ; ມັນແມ່ນກ່ຽວກັບ "ການເກັບຮັກສາ EAV ທີ່ມີຮູບແບບຂໍ້ມູນຄ້າຍຄື RDF."

ອາດຈະເປັນ, ຄວາມແຕກຕ່າງຂອງລະດັບຄວາມຮັກຕໍ່ເຕັກໂນໂລຢີທີ່ສອດຄ້ອງກັນຂອງສະຖາບັນການເງິນພາຍໃນແລະຕາເວັນຕົກແມ່ນຍ້ອນລັກສະນະຂ້າມຊາດຂອງກິດຈະກໍາສຸດທ້າຍ. ປາກົດຂື້ນວ່າ, ການເຊື່ອມໂຍງຂ້າມຊາຍແດນຂອງລັດຮຽກຮ້ອງໃຫ້ມີການແກ້ໄຂອົງການຈັດຕັ້ງແລະດ້ານວິຊາການທີ່ແຕກຕ່າງກັນ.

• ລະບົບຄໍາຖາມຄໍາຕອບກັບຄໍາຮ້ອງສະຫມັກການຄ້າ (IBM Watson, Apple Siri, Google Knowledge Graph);

ປະຈຸບັນ

ໂດຍວິທີທາງການ, ຜູ້ສ້າງ Siri, Thomas Gruber, ແມ່ນຜູ້ຂຽນຂອງຄໍານິຍາມຂອງ ontology (ໃນຄວາມຫມາຍ IT) ເປັນ "ການກໍານົດແນວຄວາມຄິດ." ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ການຈັດລຽງຄໍາສັບໃຫມ່ໃນຄໍານິຍາມນີ້ບໍ່ໄດ້ປ່ຽນຄວາມຫມາຍຂອງມັນ, ເຊິ່ງບາງທີອາດຊີ້ໃຫ້ເຫັນວ່າມັນບໍ່ມີ.

• ການພິມເຜີຍແຜ່ຂໍ້ມູນທີ່ມີໂຄງສ້າງ (ມີເຫດຜົນຫຼາຍກວ່ານີ້, ນີ້ສາມາດຖືກລວມເຂົ້າກັບຂໍ້ມູນເປີດທີ່ເຊື່ອມຕໍ່).

ປະຈຸບັນ

ແຟນໃຫຍ່ຂອງ Linked Data ແມ່ນອັນທີ່ເອີ້ນວ່າ GLAM: Galleries, Library, Archives, ແລະ Museums. ມັນພຽງພໍທີ່ຈະເວົ້າວ່າຫໍສະຫມຸດຂອງກອງປະຊຸມແມ່ນສົ່ງເສີມການທົດແທນສໍາລັບ MARC21 BIBFRAME, ເຊິ່ງ ສະຫນອງພື້ນຖານສໍາລັບອະນາຄົດຂອງຄໍາອະທິບາຍບັນນານຸກົມ ແລະ, ແນ່ນອນ, ອີງໃສ່ RDF.

Wikidata ມັກຈະຖືກກ່າວເຖິງເປັນຕົວຢ່າງຂອງໂຄງການທີ່ປະສົບຜົນສໍາເລັດໃນພາກສະຫນາມຂອງ Linked Open Data - ປະເພດຂອງ Wikipedia ສະບັບທີ່ເຄື່ອງຈັກສາມາດອ່ານໄດ້, ເນື້ອໃນທີ່ກົງກັນຂ້າມກັບ DBPedia, ບໍ່ໄດ້ສ້າງຂຶ້ນໂດຍການນໍາເຂົ້າຈາກກ່ອງຂໍ້ມູນບົດຄວາມ, ແຕ່ເປັນ. ສ້າງດ້ວຍຕົນເອງຫຼາຍຫຼືຫນ້ອຍ (ແລະຕໍ່ມາກາຍເປັນແຫຼ່ງຂໍ້ມູນສໍາລັບກ່ອງຂໍ້ມູນດຽວກັນ).

ພວກເຮົາຍັງແນະນໍາໃຫ້ທ່ານກວດເບິ່ງມັນອອກ ບັນຊີລາຍຊື່ ຜູ້ໃຊ້ເກັບຮັກສາ Stardog RDF ຢູ່ໃນເວັບໄຊທ໌ Stardog ໃນສ່ວນ "ລູກຄ້າ".

ເປັນໄປໄດ້, ໃນ Gartner Hype Cycle ສໍາລັບເຕັກໂນໂລຊີທີ່ເກີດໃຫມ່ 2016 "ການຄຸ້ມຄອງການເກັບພາສີແລະ Ontology ຂອງວິສາຫະກິດ" ແມ່ນຖືກຈັດໃສ່ໃນກາງຂອງການສືບເຊື້ອສາຍເຂົ້າໄປໃນຮ່ອມພູຂອງຄວາມຜິດຫວັງກັບຄວາມສົດໃສດ້ານທີ່ຈະໄປເຖິງ "ພູພຽງຜົນຜະລິດ" ບໍ່ໄວກ່ວາໃນ 10 ປີ.

ການເຊື່ອມຕໍ່ຂໍ້ມູນວິສາຫະກິດ

ພະຍາກອນ, ພະຍາກອນ, ພະຍາກອນ...

ດ້ວຍຄວາມສົນໃຈທາງປະຫວັດສາດ, ຂ້າພະເຈົ້າໄດ້ຈັດຕາຕະລາງຂ້າງລຸ່ມນີ້ການຄາດຄະເນຂອງ Gartner ສໍາລັບປີຕ່າງໆກ່ຽວກັບເຕັກໂນໂລຢີທີ່ພວກເຮົາສົນໃຈ.

ປີ	ເທກໂນໂລຍີ	ບົດລາຍງານ	ຕໍາແຫນ່ງ	ປີໄປຫາພູພຽງ
2001	Web Semantic	ເຕັກໂນໂລຢີທີ່ພົ້ນເດັ່ນຂື້ນ	ຕົວກະຕຸ້ນນະວັດຕະກໍາ	5​-10
2006	ເວັບ Semantic ຂອງບໍລິສັດ	ເຕັກໂນໂລຢີທີ່ພົ້ນເດັ່ນຂື້ນ	ສູງສຸດຂອງຄວາມຄາດຫວັງຂອງອັດຕາເງິນເຟີ້	5​-10
2012	Web Semantic	Big Data	ສູງສຸດຂອງຄວາມຄາດຫວັງຂອງອັດຕາເງິນເຟີ້	> 10
2015	ຂໍ້ມູນເຊື່ອມຕໍ່	ການວິເຄາະຂັ້ນສູງ ແລະວິທະຍາສາດຂໍ້ມູນ	Trough ຂອງ Disillusionment	5​-10
2016	ການຄຸ້ມຄອງ Ontology ວິສາຫະກິດ	ເຕັກໂນໂລຢີທີ່ພົ້ນເດັ່ນຂື້ນ	Trough ຂອງ Disillusionment	> 10
2018	ຕາຕະລາງຄວາມຮູ້	ເຕັກໂນໂລຢີທີ່ພົ້ນເດັ່ນຂື້ນ	ຕົວກະຕຸ້ນນະວັດຕະກໍາ	5​-10

ຢ່າງໃດກໍຕາມ, ຢູ່ໃນແລ້ວ "Hype Cycle..." 2018 ແນວໂນ້ມທີ່ເພີ່ມຂຶ້ນອີກອັນຫນຶ່ງໄດ້ປະກົດຂຶ້ນ - Knowledge Graphs. ການເກີດໃຫມ່ທີ່ແນ່ນອນເກີດຂຶ້ນ: ເສັ້ນສະແດງ DBMSs, ເຊິ່ງຄວາມສົນໃຈຂອງຜູ້ໃຊ້ແລະຄວາມພະຍາຍາມຂອງນັກພັດທະນາໄດ້ຫັນປ່ຽນ, ພາຍໃຕ້ອິດທິພົນຂອງຄໍາຮ້ອງຂໍຂອງອະດີດແລະນິໄສຂອງຍຸກສຸດທ້າຍ, ໄດ້ເລີ່ມຕົ້ນທີ່ຈະເອົາຮູບຊົງແລະການຈັດຕໍາແຫນ່ງ. ຂອງຄູ່ແຂ່ງກ່ອນຫນ້າຂອງພວກເຂົາ.

ເກືອບທຸກກຣາຟ DBMS ໃນປັດຈຸບັນປະກາດຕົນເອງເປັນເວທີທີ່ເຫມາະສົມສໍາລັບການສ້າງ "ກາຟຄວາມຮູ້" ຂອງບໍລິສັດ ("ຂໍ້ມູນເຊື່ອມຕໍ່" ບາງຄັ້ງຖືກແທນທີ່ດ້ວຍ "ຂໍ້ມູນເຊື່ອມຕໍ່"), ແຕ່ວ່າການຮຽກຮ້ອງດັ່ງກ່າວມີຄວາມຍຸດຕິທໍາແນວໃດ?

ຖານຂໍ້ມູນກຣາບຍັງຄົງເປັນ asemantic; ຂໍ້ມູນໃນກຣາບ DBMS ຍັງຄົງເປັນຂໍ້ມູນດຽວກັນ. String identifiers ແທນ URIs ເຮັດໃຫ້ວຽກງານຂອງການລວມສອງກາຟ DBMSs ຍັງເປັນວຽກງານການເຊື່ອມໂຍງ, ໃນຂະນະທີ່ການລວມເອົາສອງຮ້ານ RDF ມັກຈະລົງມາພຽງແຕ່ການລວມສອງກາຟ RDF. ອີກດ້ານຫນຶ່ງຂອງ asemanticity ແມ່ນການບໍ່ສະທ້ອນຂອງຮູບແບບກາຟ LPG, ເຊິ່ງເຮັດໃຫ້ມັນຍາກທີ່ຈະຈັດການ metadata ໂດຍໃຊ້ເວທີດຽວກັນ.

ສຸດທ້າຍ, graph DBMSs ບໍ່ມີເຄື່ອງຈັກ inference ຫຼືເຄື່ອງຈັກກົດລະບຽບ. ຜົນໄດ້ຮັບຂອງເຄື່ອງຈັກດັ່ງກ່າວສາມາດຜະລິດຄືນໄດ້ໂດຍການສອບຖາມທີ່ສັບສົນ, ແຕ່ນີ້ແມ່ນເປັນໄປໄດ້ເຖິງແມ່ນວ່າໃນ SQL.

ຢ່າງໃດກໍ່ຕາມ, ລະບົບເກັບຮັກສາ RDF ຊັ້ນນໍາບໍ່ມີຄວາມຫຍຸ້ງຍາກໃນການສະຫນັບສະຫນູນຮູບແບບ LPG. ວິທີການທີ່ແຂງທີ່ສຸດແມ່ນຖືວ່າເປັນຫນຶ່ງທີ່ສະເຫນີໃນເວລາດຽວໃນ Blazegraph: ຮູບແບບ RDF *, ປະສົມປະສານ RDF ແລະ LPG.

ອ່ານ​ເພີ່ມ​ເຕີມ

ທ່ານ​ສາ​ມາດ​ອ່ານ​ເພີ່ມ​ເຕີມ​ກ່ຽວ​ກັບ​ການ​ສະ​ຫນັບ​ສະ​ຫນູນ​ການ​ເກັບ​ຮັກ​ສາ RDF ສໍາ​ລັບ​ຮູບ​ແບບ LPG ໃນ​ບົດ​ຄວາມ​ທີ່​ຜ່ານ​ມາ​ກ່ຽວ​ກັບ Habré​: "ມີຫຍັງເກີດຂື້ນກັບການເກັບຮັກສາ RDF ດຽວນີ້". ຂ້າພະເຈົ້າຫວັງວ່າມື້ຫນຶ່ງບົດຄວາມແຍກຕ່າງຫາກຈະຖືກຂຽນກ່ຽວກັບ Knowledge Graphs ແລະ Data Fabric. ພາກສຸດທ້າຍ, ຕາມທີ່ເຂົ້າໃຈງ່າຍ, ໄດ້ຖືກຂຽນຢ່າງຮີບດ່ວນ, ຢ່າງໃດກໍຕາມ, ເຖິງແມ່ນວ່າຫົກເດືອນຕໍ່ມາ, ທຸກສິ່ງທຸກຢ່າງແມ່ນບໍ່ມີຄວາມຊັດເຈນຫຼາຍກັບແນວຄວາມຄິດເຫຼົ່ານີ້.

Literature

1. Halpin, H., Monnin, A. (eds.) (2014). ວິສະວະກໍາປັດຊະຍາ: ໄປສູ່ປັດຊະຍາຂອງເວັບ
2. Allemang, D., Hendler, J. (2011) Semantic Web for the Working Ontologist (2nd ed.)
3. Staab, S., Studer, R. (eds.) (2009) Handbook on Ontologies (2nd ed.)
4. ໄມ້, D. (ed.). (2011) ການເຊື່ອມໂຍງຂໍ້ມູນວິສາຫະກິດ
5. Keet, M. (2018) ການແນະນໍາວິສະວະກໍາ Ontology

ແຫຼ່ງຂໍ້ມູນ: www.habr.com