គេហទំព័រ Semantic និងទិន្នន័យភ្ជាប់។ ការកែតម្រូវនិងការបន្ថែម

ខ្ញុំ​ចង់​បង្ហាញ​ដល់​សាធារណជន​នូវ​បំណែក​នៃ​សៀវភៅ​ដែល​ទើប​ចេញ​ផ្សាយ​ថ្មីៗ​នេះ៖

គំរូ 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 សង់ទីម៉ែត្រ - អ្នកនិពន្ធ។ បានបង្ហាញនៅលើ tit ខាងក្រោយ។ ជាមួយ។ - គន្ថនិទ្ទេស នៅចុងបញ្ចប់នៃ ch ។ - ISBN 978-5-7996-2580-1: 200 ច្បាប់ចម្លង។

គោលបំណងនៃការបង្ហោះបំណែកនេះនៅលើ Habre គឺបួនដង៖

• វាមិនទំនងទេដែលថានរណាម្នាក់នឹងអាចកាន់សៀវភៅនេះនៅក្នុងដៃរបស់ពួកគេប្រសិនបើគាត់មិនមែនជាអតិថិជននៃការគោរព SergeIndex; វាប្រាកដជាមិនមានលក់ទេ។
• ការកែតម្រូវត្រូវបានធ្វើឡើងចំពោះអត្ថបទ (ពួកវាមិនត្រូវបានបន្លិចខាងក្រោមទេ) ហើយការបន្ថែមត្រូវបានធ្វើឡើងដែលមិនស៊ីគ្នាជាមួយទម្រង់នៃអក្សរកាត់ដែលបានបោះពុម្ព៖ កំណត់ចំណាំប្រធានបទ (ក្រោមការបង្ខូច) និងតំណខ្ពស់។
• ខ្ញុំ​ចង់ ប្រមូលសំណួរនិងយោបល់ដើម្បីយកវាទៅក្នុងគណនីនៅពេលរួមបញ្ចូលអត្ថបទនេះនៅក្នុងទម្រង់ដែលបានកែប្រែនៅក្នុងការបោះពុម្ពផ្សេងទៀតណាមួយ។
• អ្នកប្រកាន់ភ្ជាប់ Semantic Web និង Linked Data ជាច្រើននៅតែជឿថារង្វង់របស់ពួកគេតូចចង្អៀត ភាគច្រើនដោយសារតែសាធារណៈជនទូទៅមិនទាន់ត្រូវបានពន្យល់ឱ្យបានត្រឹមត្រូវថាតើវាអស្ចារ្យប៉ុណ្ណាក្នុងការក្លាយជាអ្នកប្រកាន់ខ្ជាប់នៃ Semantic Web និង Linked Data ។ អ្នកនិពន្ធនៃបំណែកនេះ ទោះបីជាគាត់ជាកម្មសិទ្ធិរបស់រង្វង់នេះក៏ដោយ មិនប្រកាន់គំនិតនេះទេ ប៉ុន្តែទោះជាយ៉ាងណា ចាត់ទុកថាខ្លួនគាត់មានកាតព្វកិច្ចក្នុងការព្យាយាមមួយផ្សេងទៀត។

ហើយដូច្នេះ,

វេបសាយថល

ការវិវត្តន៍នៃអ៊ីនធឺណិតអាចត្រូវបានតំណាងដូចខាងក្រោម (ឬនិយាយអំពីផ្នែករបស់វាដែលត្រូវបានបង្កើតឡើងតាមលំដាប់ដែលបានចង្អុលបង្ហាញខាងក្រោម):

1. ឯកសារនៅលើអ៊ីនធឺណិត. បច្ចេកវិទ្យាសំខាន់ៗ - Gopher, FTP ។ល។
   អ៊ិនធឺណិតគឺជាបណ្តាញសកលសម្រាប់ការផ្លាស់ប្តូរធនធានក្នុងស្រុក។
2. ឯកសារតាមអ៊ីនធឺណិត. បច្ចេកវិទ្យាសំខាន់ៗគឺ HTML និង HTTP ។
   ធម្មជាតិនៃធនធានដែលបានលាតត្រដាងយកទៅក្នុងគណនីលក្ខណៈនៃឧបករណ៍បញ្ជូនរបស់ពួកគេ។
3. ទិន្នន័យអ៊ីនធឺណិត. បច្ចេកវិទ្យាសំខាន់ៗ - REST និង SOAP API, XHR ជាដើម។
   យុគសម័យនៃកម្មវិធីអ៊ីនធឺណិត មិនត្រឹមតែមនុស្សក្លាយជាអ្នកប្រើប្រាស់ធនធានប៉ុណ្ណោះទេ។
4. ទិន្នន័យអ៊ីនធឺណិត. បច្ចេកវិទ្យាសំខាន់ៗគឺ បច្ចេកវិទ្យាភ្ជាប់ទិន្នន័យ។
   ដំណាក់កាលទីបួននេះ ព្យាករណ៍ដោយ Berners-Lee ដែលជាអ្នកបង្កើតបច្ចេកវិទ្យាស្នូលទីពីរ និងជានាយក W3C ត្រូវបានគេហៅថា Semantic Web ។ បច្ចេកវិទ្យាទិន្នន័យភ្ជាប់ត្រូវបានរចនាឡើងដើម្បីធ្វើឱ្យទិន្នន័យនៅលើគេហទំព័រមិនត្រឹមតែអាចអានដោយម៉ាស៊ីនប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំង "អាចយល់បានដោយម៉ាស៊ីន" ផងដែរ។

ពីអ្វីដែលខាងក្រោមនេះ អ្នកអាននឹងយល់ពីការឆ្លើយឆ្លងរវាងគោលគំនិតសំខាន់ៗនៃដំណាក់កាលទីពីរ និងទីបួន៖

• URLs គឺស្រដៀងនឹង URIs
• analogue នៃ HTML គឺ RDF,
• តំណខ្ពស់ HTML គឺស្រដៀងទៅនឹងការកើតឡើង URI នៅក្នុងឯកសារ RDF ។

គេហទំព័រ Semantic គឺជាទស្សនវិស័យជាប្រព័ន្ធនៃអនាគតនៃអ៊ីនធឺណិត ជាងនិន្នាការជាក់លាក់មួយដោយឯកឯង ឬមានការបញ្ចុះបញ្ចូល ទោះបីជាវាអាចយកមកពិចារណាលើផ្នែកចុងក្រោយទាំងនេះក៏ដោយ។ ឧទាហរណ៍ លក្ខណៈសំខាន់នៃអ្វីដែលហៅថា គេហទំព័រ 2.0 ត្រូវបានចាត់ទុកថាជា "មាតិកាបង្កើតដោយអ្នកប្រើប្រាស់"។ ជាពិសេស អនុសាសន៍ W3C ត្រូវបានអំពាវនាវឱ្យយកវាទៅក្នុងគណនី "Web Annotation Ontology"និង​កិច្ច​ការ​ដូច​ជា​ រឹង.

តើ Semantic Web ស្លាប់ឬ?

ប្រសិនបើអ្នកបដិសេធ ការរំពឹងទុកមិនប្រាកដប្រជាស្ថានភាពជាមួយបណ្តាញ semantic គឺប្រហាក់ប្រហែលនឹងកុម្មុយនិស្តក្នុងកំឡុងសម័យសង្គមនិយមដែលបានអភិវឌ្ឍ (ហើយថាតើភាពស្មោះត្រង់ចំពោះលក្ខខណ្ឌតាមលក្ខខណ្ឌរបស់ Ilyich ត្រូវបានគេសង្កេតឃើញដែរឬទេ អនុញ្ញាតឱ្យមនុស្សគ្រប់គ្នាសម្រេចចិត្តដោយខ្លួនឯង)។ ម៉ាស៊ីនស្វែងរក យ៉ាងជោគជ័យ បង្ខំគេហទំព័រឱ្យប្រើ RDFa និង JSON-LD ហើយខ្លួនគេប្រើបច្ចេកវិទ្យាដែលទាក់ទងនឹងអ្វីដែលបានពិពណ៌នាខាងក្រោម (Google Knowledge Graph, Bing Knowledge Graph) ។

ជាទូទៅ អ្នកនិពន្ធមិនអាចនិយាយអ្វីដែលរារាំងការរីករាលដាលកាន់តែខ្លាំងនោះទេ ប៉ុន្តែគាត់អាចនិយាយដោយផ្អែកលើបទពិសោធន៍ផ្ទាល់ខ្លួន។ មានបញ្ហាដែលអាចដោះស្រាយបាន "ក្រៅប្រអប់" នៅក្នុងលក្ខខណ្ឌនៃការវាយលុក SW ទោះបីជាវាមិនរីករាលដាលខ្លាំងក៏ដោយ។ ជាលទ្ធផល អ្នកដែលត្រូវប្រឈមមុខនឹងការងារទាំងនេះ គ្មានមធ្យោបាយបង្ខិតបង្ខំប្រឆាំងនឹងអ្នកដែលអាចផ្តល់ដំណោះស្រាយបានទេ ខណៈដែលការផ្តល់ដំណោះស្រាយឯករាជ្យចុងក្រោយនេះផ្ទុយពីគំរូអាជីវកម្មរបស់ពួកគេ។ ដូច្នេះ យើងបន្តញែក HTML និងភ្ជាប់ APIs ផ្សេងៗ ជាមួយគ្នា។

ទោះជាយ៉ាងណាក៏ដោយ បច្ចេកវិទ្យាទិន្នន័យដែលបានភ្ជាប់បានរីករាលដាលលើសពីបណ្តាញចរន្ត។ តាមពិតសៀវភៅនេះត្រូវបានឧទ្ទិសដល់កម្មវិធីទាំងនេះ។ បច្ចុប្បន្ននេះ សហគមន៍ទិន្នន័យដែលបានតភ្ជាប់រំពឹងថាបច្ចេកវិទ្យាទាំងនេះនឹងកាន់តែរីករាលដាលដោយសារការកត់ត្រារបស់ Gartner (ឬការប្រកាសតាមដែលអ្នកចូលចិត្ត) នៃនិន្នាការដូចជា ក្រាហ្វិចចំណេះដឹង и ក្រណាត់ទិន្នន័យ. ខ្ញុំចង់ជឿថាវានឹងមិនមែនជាការអនុវត្ត "កង់" នៃគំនិតទាំងនេះដែលនឹងទទួលបានជោគជ័យនោះទេ ប៉ុន្តែអ្វីដែលទាក់ទងទៅនឹងស្តង់ដារ W3C ដែលបានពិភាក្សាខាងក្រោម។

ទិន្នន័យភ្ជាប់

Berners-Lee បានកំណត់ទិន្នន័យភ្ជាប់ថាជាគេហទំព័រ semantic "ធ្វើបានត្រឹមត្រូវ"៖ សំណុំនៃវិធីសាស្រ្ត និងបច្ចេកវិទ្យាដែលអនុញ្ញាតឱ្យវាសម្រេចបាននូវគោលដៅចុងក្រោយរបស់វា។ គោលការណ៍ជាមូលដ្ឋាននៃទិន្នន័យភ្ជាប់ Berners-Lee បន្លិច លំនាំ​តាម។

គោលការណ៍ ១. ការប្រើប្រាស់ URIs ដើម្បីដាក់ឈ្មោះអង្គភាព។

URIs គឺជាឧបករណ៍កំណត់អត្តសញ្ញាណសកលដែលផ្ទុយពីការកំណត់អត្តសញ្ញាណខ្សែអក្សរក្នុងតំបន់សម្រាប់ធាតុ។ ក្រោយមក គោលការណ៍នេះត្រូវបានបង្ហាញយ៉ាងល្អបំផុតនៅក្នុងពាក្យស្លោក Google Knowledge Graph “រឿង មិនមែនខ្សែទេ។"។

គោលការណ៍ ១. ការប្រើប្រាស់ URIs នៅក្នុងគ្រោងការណ៍ HTTP ដូច្នេះពួកគេអាចត្រូវបានគេបដិសេធ។

ដោយ​យោង​ទៅ​លើ URI វា​គួរ​តែ​អាច​ធ្វើ​ទៅ​បាន​ដើម្បី​ទទួល​បាន​សញ្ញា​នៅ​ពី​ក្រោយ​សញ្ញា​នោះ (ភាព​ស្រដៀង​គ្នា​ជាមួយ​នឹង​ឈ្មោះ​របស់​ប្រតិបត្តិករ " គឺ​ច្បាស់​នៅ​ទីនេះ​) ។*"នៅក្នុង C); កាន់តែច្បាស់ ដើម្បីទទួលបានតំណាងមួយចំនួននៃសញ្ញានេះ - អាស្រ័យលើតម្លៃនៃបឋមកថា HTTP Accept:. ប្រហែលជាជាមួយនឹងការមកដល់នៃយុគសម័យ AR/VR វានឹងអាចទទួលបានធនធានដោយខ្លួនឯង ប៉ុន្តែសម្រាប់ពេលនេះ ទំនងជាវានឹងក្លាយជាឯកសារ RDF ដែលជាលទ្ធផលនៃការប្រតិបត្តិសំណួរ SPARQL DESCRIBE.

គោលការណ៍ ១. ការប្រើប្រាស់ស្តង់ដារ W3C - ជាចម្បង RDF(S) និង SPARQL - ជាពិសេសនៅពេលបដិសេធ URIs ។

"ស្រទាប់" នីមួយៗនៃជង់បច្ចេកវិទ្យាទិន្នន័យភ្ជាប់ ដែលត្រូវបានគេស្គាល់ថាជា នំស្រទាប់បណ្តាញ Semanticនឹងត្រូវបានពិពណ៌នាខាងក្រោម។

គោលការណ៍ ១. ការប្រើប្រាស់ឯកសារយោងទៅ URIs ផ្សេងទៀតនៅពេលពិពណ៌នាអំពីអង្គភាព។

RDF អនុញ្ញាតឱ្យអ្នកដាក់កម្រិតខ្លួនអ្នកទៅនឹងការពិពណ៌នាពាក្យសំដីនៃធនធានជាភាសាធម្មជាតិ ហើយគោលការណ៍ទី XNUMX ហៅថាកុំធ្វើរឿងនេះ។ ប្រសិនបើគោលការណ៍ទីមួយត្រូវបានគេសង្កេតឃើញជាសកល វាអាចទៅរួចនៅពេលពិពណ៌នាអំពីធនធានដើម្បីយោងទៅអ្នកដទៃ រួមទាំង "បរទេស" ដែលជាមូលហេតុដែលទិន្នន័យត្រូវបានគេហៅថាភ្ជាប់។ តាមពិតទៅ វាស្ទើរតែជៀសមិនរួចក្នុងការប្រើប្រាស់ URIs ដែលមានឈ្មោះក្នុងវាក្យសព្ទ RDFS ។

RDF

RDF (ក្របខ័ណ្ឌការពិពណ៌នាធនធាន) គឺជាទម្រង់បែបបទសម្រាប់ការពិពណ៌នាអំពីអង្គភាពពាក់ព័ន្ធ។

សេចក្តីថ្លែងការណ៍នៃប្រភេទ "ប្រធានបទ-ទស្សន៍ទាយ-វត្ថុ" ដែលហៅថា triplets ត្រូវបានធ្វើឡើងអំពីអង្គភាព និងទំនាក់ទំនងរបស់ពួកគេ។ ក្នុងករណីសាមញ្ញបំផុត ប្រធានបទ ទស្សន៍ទាយ និងវត្ថុគឺជា URI ទាំងអស់។ URI ដូចគ្នាអាចស្ថិតនៅក្នុងទីតាំងផ្សេងគ្នាក្នុងបីបីផ្សេងគ្នា៖ ជាប្រធានបទ ទស្សន៍ទាយ និងវត្ថុមួយ។ ដូច្នេះ បីដងបង្កើតបានជាប្រភេទក្រាហ្វដែលហៅថាក្រាហ្វ RDF ។

វត្ថុ និងវត្ថុអាចមិនត្រឹមតែជា URI ប៉ុណ្ណោះទេ ថែមទាំងហៅថា ថ្នាំងទទេហើយវត្ថុក៏អាចជា ព្យញ្ជនៈ. ព្យញ្ជនៈគឺជាឧទាហរណ៍នៃប្រភេទបុព្វកាលដែលមានតំណាងខ្សែអក្សរ និងការចង្អុលបង្ហាញប្រភេទ។

ឧទាហរណ៍នៃការសរសេរព្យញ្ជនៈ (នៅក្នុងវាក្យសម្ព័ន្ធអណ្តើក បន្ថែមអំពីវាខាងក្រោម)៖ "5.0"^^xsd:float и "five"^^xsd:string. ព្យញ្ជនៈជាមួយប្រភេទ rdf:langString ក៏អាចត្រូវបានបំពាក់ដោយស្លាកភាសា; នៅក្នុងអណ្តើកវាត្រូវបានសរសេរដូចនេះ: "five"@en и "пять"@ru.

ថ្នាំងទទេគឺជាធនធាន "អនាមិក" ដោយគ្មានឧបករណ៍កំណត់អត្តសញ្ញាណសកល អំពីអ្វីដែលសេចក្តីថ្លែងការណ៍អាចត្រូវបានធ្វើឡើង។ ប្រភេទនៃអថេរអត្ថិភាព។

ដូច្នេះ (តាមពិតចំណុចទាំងមូលនៃ RDF)៖

• ប្រធានបទគឺជា URI ឬថ្នាំងទទេ
• ការព្យាករណ៍គឺ URI,
• វត្ថុគឺជា URI ថ្នាំងទទេ ឬព្យញ្ជនៈ។

ហេតុអ្វីបានជាការព្យាករណ៍មិនអាចជាថ្នាំងទទេ?

ហេតុផលដែលអាចកើតមានគឺការចង់យល់ក្រៅផ្លូវការ និងបកប្រែ triplet ទៅជាភាសានៃតក្កវិជ្ជាលំដាប់ទីមួយ s p o ដូចជាអ្វីមួយដូចជា ដែលជាកន្លែង - ព្យាករណ៍, и - ថេរ។ ដាននៃការយល់ដឹងនេះមាននៅក្នុងឯកសារ "LBase : Semantics សម្រាប់ភាសានៃ Semantic Web"ដែលមានស្ថានភាពនៃកំណត់ត្រាក្រុមការងារ W3C ។ ជាមួយនឹងការយល់ដឹងនេះ, បី s p []ដែលជាកន្លែង [] - ថ្នាំងទទេនឹងត្រូវបានបកប្រែជា ដែលជាកន្លែង - អថេរ ប៉ុន្តែរបៀបបកប្រែ s [] o? ឯកសារដែលមានស្ថានភាពអនុសាសន៍ W3C "RDF 1.1 អត្ថន័យ” ផ្តល់នូវវិធីសាស្រ្តបកប្រែមួយផ្សេងទៀត ប៉ុន្តែនៅតែមិនគិតពីលទ្ធភាពនៃការព្យាករណ៍ជាថ្នាំងទទេ។

ទោះយ៉ាងណាក៏ដោយ Manu Sporni អនុញ្ញាត.

RDF គឺជាគំរូអរូបី។ RDF អាចត្រូវបានសរសេរ (សៀរៀល) នៅក្នុងវាក្យសម្ព័ន្ធផ្សេងៗ៖ RDF/XML, អណ្តើក (មនុស្សភាគច្រើនអាចអានបាន), JSON-LD, អេធីធី (ប្រព័ន្ធគោលពីរ) ។

RDF ដូចគ្នាអាចត្រូវបានសៀរៀលទៅក្នុង RDF/XML តាមវិធីផ្សេងៗគ្នា ដូច្នេះឧទាហរណ៍ វាគ្មានន័យទេក្នុងការកំណត់លទ្ធផល XML ដោយប្រើ XSD ឬព្យាយាមទាញយកទិន្នន័យដោយប្រើ XPath ។ ដូចគ្នានេះដែរ JSON-LD ទំនងជាមិនបំពេញបំណងរបស់អ្នកអភិវឌ្ឍន៍ Javascript ជាមធ្យមក្នុងការធ្វើការជាមួយ RDF ដោយប្រើសញ្ញាចំណុច និងតង្កៀបការ៉េរបស់ Javascript (ទោះបីជា JSON-LD ផ្លាស់ទីក្នុងទិសដៅនោះដោយផ្តល់នូវយន្តការមួយ។ ស៊ុម).

វាក្យសម្ព័ន្ធភាគច្រើនផ្តល់នូវវិធីដើម្បីកាត់បន្ថយ URIs វែង។ ឧទាហរណ៍ការផ្សាយពាណិជ្ជកម្ម @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.

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 និង RDF Query Language) - ភាសាសម្រាប់សួរទិន្នន័យ RDF ។ ក្នុងករណីដ៏សាមញ្ញមួយ សំណួរ SPARQL គឺជាសំណុំនៃគំរូមួយ ដែលក្រាហ្វបីដងដែលត្រូវបានសួរត្រូវបានផ្គូផ្គង។ លំនាំអាចមានអថេរនៅក្នុងមុខវិជ្ជា ទស្សន៍ទាយ និងទីតាំងវត្ថុ។

សំណួរ​នឹង​ត្រឡប់​តម្លៃ​អថេរ​បែបនេះ ដែល​នៅពេល​ត្រូវបាន​ជំនួស​ទៅក្នុង​គំរូ អាច​ជា​លទ្ធផល​នៅក្នុង​ក្រាហ្វ​នៃ​ក្រាហ្វ RDF ដែល​បាន​សួរ (សំណុំ​រង​នៃ​បីដង​របស់វា)។ អថេរនៃឈ្មោះដូចគ្នានៅក្នុងគំរូផ្សេងគ្នានៃ triplets ត្រូវតែមានតម្លៃដូចគ្នា។

ឧទាហរណ៍ ដោយបានផ្តល់ឱ្យនូវសំណុំខាងលើនៃ RDFS axioms ប្រាំពីរ សំណួរខាងក្រោមនឹងត្រលប់មកវិញ 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 - មិនមាន analogues ផ្ទាល់ពីដំណាក់កាលទីពីរ (សូមមើលដើមកថាខណ្ឌនេះ)។ វា​អាច​ត្រូវ​បាន​គេ​ប្រដូច​ទៅ​នឹង​មូលដ្ឋាន​ទិន្នន័យ ដោយ​ផ្អែក​លើ​មាតិកា​ដែល​ទំព័រ HTML ត្រូវ​បាន​បង្កើត ប៉ុន្តែ​អាច​ចូល​ប្រើ​បាន​ដោយ​អ្នក​ខាងក្រៅ។ ចំណុចចូលប្រើ SPARQL គឺស្រដៀងទៅនឹងចំណុចចូលប្រើ API ពីដំណាក់កាលទីបី ប៉ុន្តែមានភាពខុសគ្នាសំខាន់ពីរ។ ទីមួយ វាអាចទៅរួចក្នុងការបញ្ចូលគ្នានូវសំណួរ "អាតូមិក" ជាច្រើនចូលទៅក្នុងមួយ (ដែលត្រូវបានគេចាត់ទុកថាជាលក្ខណៈសំខាន់នៃ GraphQL) ហើយទីពីរ API បែបនេះគឺជាការចងក្រងឯកសារដោយខ្លួនឯងទាំងស្រុង (ដែលជាអ្វីដែល HATEOAS ព្យាយាមសម្រេចបាន)។

សុន្ទរកថាប៉ូឡូញ

RDF គឺជាមធ្យោបាយមួយដើម្បីផ្សព្វផ្សាយទិន្នន័យនៅលើគេហទំព័រ ដូច្នេះការផ្ទុក RDF គួរតែត្រូវបានចាត់ទុកថាជាឯកសារ DBMS ។ ពិត ដោយសារ RDF គឺជាក្រាហ្វ ហើយមិនមែនជាមែកធាង ពួកវាក៏ប្រែទៅជាក្រាហ្វផងដែរ។ វាអស្ចារ្យណាស់ដែលវាដំណើរការទាំងអស់។ តើអ្នកណានឹងគិតថានឹងមានមនុស្សឆ្លាតដែលនឹងអនុវត្តថ្នាំងទទេ។ Codd នៅទីនេះ វាមិនដំណើរការទេ។.

វាក៏មានវិធីដែលមានលក្ខណៈពេញលេញតិចជាងក្នុងការរៀបចំការចូលប្រើទិន្នន័យ RDF ឧទាហរណ៍។ បំណែកទិន្នន័យដែលបានភ្ជាប់ (LDF) និង វេទិកាទិន្នន័យភ្ជាប់ (LDP) ។

OWL

OWL (Web Ontology Language) - ទម្រង់បែបបទសម្រាប់តំណាងឱ្យចំណេះដឹង កំណែវាក្យសម្ព័ន្ធនៃតក្កវិជ្ជាពិពណ៌នា (នៅគ្រប់ទីកន្លែងខាងក្រោមវាកាន់តែត្រឹមត្រូវក្នុងការនិយាយថា OWL 2 កំណែដំបូងនៃ OWL ត្រូវបានផ្អែកលើ ).

គោលគំនិតនៃតក្កវិជ្ជាពិពណ៌នានៅក្នុង OWL ត្រូវគ្នាទៅនឹងថ្នាក់ តួនាទីត្រូវគ្នានឹងលក្ខណៈសម្បត្តិ បុគ្គលរក្សាឈ្មោះមុនរបស់ពួកគេ។ Axioms ត្រូវបានគេហៅថា axioms ផងដែរ។

ឧទាហរណ៍នៅក្នុងអ្វីដែលគេហៅថា វាក្យសម្ព័ន្ធ Manchester សម្រាប់សញ្ញាណ OWL គឺជា axiom ដែលស្គាល់យើងរួចហើយ នឹងត្រូវបានសរសេរដូចនេះ៖

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

មានវាក្យសម្ព័ន្ធផ្សេងទៀតសម្រាប់ការសរសេរ OWL ដូចជា វាក្យសម្ព័ន្ធមុខងារប្រើនៅក្នុងការបញ្ជាក់ជាផ្លូវការ និង OWL/XML. លើសពីនេះទៀត OWL អាចត្រូវបានសៀរៀល វាក្យសម្ព័ន្ធ RDF អរូបី និងបន្ថែមទៀត - នៅក្នុងវាក្យសម្ព័ន្ធជាក់លាក់ណាមួយ។

OWL មានទំនាក់ទំនងពីរជាមួយ RDF ។ នៅលើដៃមួយ, វាអាចត្រូវបានចាត់ទុកថាជាប្រភេទវចនានុក្រមដែលពង្រីក RDFS ។ ម៉្យាងវិញទៀតវាគឺជាទម្រង់បែបបទដ៏មានឥទ្ធិពលដែល RDF គ្រាន់តែជាទម្រង់សៀរៀលប៉ុណ្ណោះ។ មិនមែនសំណង់ OWL បឋមទាំងអស់អាចត្រូវបានសរសេរដោយប្រើ RDF triplet តែមួយទេ។

អាស្រ័យលើសំណុំរងនៃសំណង់ OWL ត្រូវបានអនុញ្ញាតឱ្យប្រើ ពួកគេនិយាយអំពីអ្វីដែលគេហៅថា ទម្រង់ OWL. ស្តង់ដារនិងល្បីល្បាញបំផុតគឺ OWL EL, OWL RL និង OWL QL ។ ជម្រើសនៃទម្រង់ប៉ះពាល់ដល់ភាពស្មុគស្មាញនៃការគណនានៃបញ្ហាធម្មតា។ សំណុំពេញលេញនៃសំណង់ OWL ដែលត្រូវគ្នានឹង ហៅកាត់ថា OWL DL ។ ពេលខ្លះពួកគេក៏និយាយអំពី OWL Full ដែលការសាងសង់ OWL ត្រូវបានអនុញ្ញាតឱ្យប្រើជាមួយនឹងសេរីភាពពេញលេញដែលមាននៅក្នុង RDF ដោយមិនមានការរឹតបន្តឹងតាមន័យធៀប និងការគណនា . ឧទាហរណ៍ អ្វីមួយអាចជាថ្នាក់ និងទ្រព្យសម្បត្តិ។ OWL Full គឺមិនអាចសម្រេចបាន។

គោលការណ៍សំខាន់ៗសម្រាប់ការភ្ជាប់ផលវិបាកនៅក្នុង OWL គឺការទទួលយកការសន្មត់ពិភពលោកបើកចំហ។ អូវ៉ា) និងការបដិសេធការសន្មតនៃឈ្មោះតែមួយគត់ (សន្មត់ឈ្មោះតែមួយគត់, មួយ) ខាងក្រោមនេះយើងនឹងឃើញកន្លែងដែលគោលការណ៍ទាំងនេះអាចដឹកនាំ និងណែនាំការសាងសង់ OWL មួយចំនួន។

សូមឱ្យ ontology មានបំណែកដូចខាងក្រោម (នៅក្នុងវាក្យសម្ព័ន្ធ Manchester)៖

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

តើ​វា​នឹង​ធ្វើ​តាម​អ្វី​ដែល​បាន​និយាយ​ថា John មាន​កូន​ច្រើន​ឬ? ការបដិសេធ UNA នឹងបង្ខំម៉ាស៊ីនសន្និដ្ឋានឱ្យឆ្លើយសំណួរនេះក្នុងន័យអវិជ្ជមាន ចាប់តាំងពី Alice និង Bob ប្រហែលជាជាមនុស្សដូចគ្នា។ ដើម្បីឱ្យធាតុខាងក្រោមកើតឡើង អ្នកនឹងត្រូវបន្ថែម axiom ខាងក្រោម៖

DifferentIndividuals: Alice, Bob, Carol, John

ឥឡូវ​នេះ បំណែក​នៃ​ធាតុ​វិទ្យា​មាន​ទម្រង់​ដូច​ខាង​ក្រោម (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 ជាមួយនឹងន័យន័យធៀប មានន័យថាការបោះបង់ចោល OWA និងការអនុម័ត UNA ការអនុវត្តម៉ាស៊ីនទិន្នផលដែលត្រូវគ្នា។ - នៅតាមផ្លូវនេះ។ កំពុងមក ការផ្ទុក Stardog RDF ។
• ការបោះបង់ចោលសមត្ថភាពកាត់របស់ OWL ក្នុងការពេញចិត្តនៃម៉ាស៊ីនច្បាប់។ - Stardog គាំទ្រ SWRL; Jena និង GraphDB ផ្តល់ជូន ផ្ទាល់ខ្លួន ភាសា ច្បាប់
• ការបដិសេធសមត្ថភាពកាត់នៃ OWL ការប្រើប្រាស់សំណុំរងមួយឬផ្សេងទៀតនៅជិត RDFS សម្រាប់ការធ្វើគំរូ។ - មើលបន្ថែមអំពីរឿងនេះខាងក្រោម។

បញ្ហាមួយទៀតគឺការផ្តោតអារម្មណ៍កាន់តែខ្លាំងដែលពិភពសាជីវកម្មអាចមានលើបញ្ហាគុណភាពទិន្នន័យ និងកង្វះឧបករណ៍ផ្ទៀងផ្ទាត់ទិន្នន័យនៅក្នុងជង់ទិន្នន័យភ្ជាប់។ លទ្ធផលនៅទីនេះមានដូចខាងក្រោម។

• ជាថ្មីម្តងទៀត ប្រើសម្រាប់សុពលភាពនៃការសាងសង់ OWL ជាមួយនឹងអត្ថន័យនៃពិភពលោកបិទជិត និងឈ្មោះតែមួយគត់ ប្រសិនបើម៉ាស៊ីនសន្និដ្ឋានសមស្រប។
• ប្រើ SHACLធ្វើស្តង់ដារបន្ទាប់ពីបញ្ជីនៃស្រទាប់នំខេក Semantic Web Layer ត្រូវបានជួសជុល (ទោះជាយ៉ាងណាក៏ដោយ វាក៏អាចប្រើជាម៉ាស៊ីនច្បាប់ផងដែរ) ឬ ShEx.
• ការយល់ដឹងថាអ្វីៗគ្រប់យ៉ាងត្រូវបានធ្វើរួចជាមួយនឹងសំណួរ SPARQL បង្កើតយន្តការផ្ទៀងផ្ទាត់ទិន្នន័យសាមញ្ញរបស់អ្នកដោយប្រើពួកវា។

ទោះបីជាយ៉ាងណាក៏ដោយ សូម្បីតែការបដិសេធទាំងស្រុងនៃសមត្ថភាពកាត់កង និងឧបករណ៍សុពលភាព ទុកជង់ទិន្នន័យដែលបានភ្ជាប់ចេញពីការប្រកួតប្រជែងក្នុងកិច្ចការដែលមានលក្ខណៈស្រដៀងគ្នាទៅនឹងគេហទំព័របើកចំហ និងចែកចាយ - នៅក្នុងកិច្ចការរួមបញ្ចូលទិន្នន័យ។

ចុះប្រព័ន្ធព័ត៌មានសហគ្រាសធម្មតាវិញ?

នេះអាចទៅរួច ប៉ុន្តែជាការពិតណាស់ អ្នកគួរតែដឹងច្បាស់អំពីបញ្ហាដែលបច្ចេកវិទ្យាដែលត្រូវគ្នានឹងត្រូវដោះស្រាយ។ ខ្ញុំនឹងរៀបរាប់នៅទីនេះនូវប្រតិកម្មធម្មតារបស់អ្នកចូលរួមអភិវឌ្ឍន៍ ដើម្បីបង្ហាញពីអ្វីដែលជង់បច្ចេកវិទ្យានេះមើលទៅដូចទៅនឹងទិដ្ឋភាពនៃ IT ធម្មតា។ សូមរំឮកខ្ញុំបន្តិចអំពីប្រស្នាអំពីដំរី៖

• អ្នកវិភាគអាជីវកម្ម៖ RDF គឺ​ជា​អ្វី​មួយ​ដូច​ជា​គំរូ​ឡូជីខល​ដែល​បាន​រក្សា​ទុក​ដោយ​ផ្ទាល់។
• អ្នកវិភាគប្រព័ន្ធ៖ RDF គឺដូច អេវ៉ាមានតែជាមួយនឹងចង្កោមនៃលិបិក្រម និងភាសាសំណួរងាយស្រួលប៉ុណ្ណោះ។
• អ្នកអភិវឌ្ឍន៍: ជាការប្រសើរណាស់ នេះគឺទាំងអស់នៅក្នុងស្មារតីនៃគំនិតនៃគំរូសម្បូរបែប និងកូដទាប, កំពុងអាន ថ្មីៗនេះអំពីរឿងនេះ។
• ប្រធានគំរោង៖ បាទ​វា​ដូច​គ្នា។ ការដួលរលំជង់!

ការអនុវត្តបង្ហាញថាជង់ត្រូវបានប្រើជាញឹកញាប់បំផុតនៅក្នុងកិច្ចការដែលទាក់ទងនឹងការចែកចាយ និងភាពខុសគ្នានៃទិន្នន័យ ឧទាហរណ៍នៅពេលបង្កើតប្រព័ន្ធថ្នាក់ MDM (Master Data Management) ឬ DWH (Data Warehouse) ។ បញ្ហាបែបនេះមាននៅក្នុងឧស្សាហកម្មណាមួយ។

នៅក្នុងលក្ខខណ្ឌនៃកម្មវិធីជាក់លាក់ក្នុងឧស្សាហកម្មនេះ បច្ចេកវិជ្ជា Linked Data បច្ចុប្បន្នមានប្រជាប្រិយភាពបំផុតនៅក្នុងឧស្សាហកម្មខាងក្រោម។

• បច្ចេកវិទ្យាជីវវេជ្ជសាស្ត្រ (ដែលប្រជាប្រិយភាពរបស់ពួកគេហាក់ដូចជាទាក់ទងទៅនឹងភាពស្មុគស្មាញនៃដែន);

នា​ពេល​បច្ចុប្បន្ន

ថ្មីៗនេះ "ចំណុចរំពុះ" បានរៀបចំសន្និសីទមួយដែលរៀបចំដោយសមាគម "មូលដ្ឋានចំណេះដឹងវេជ្ជសាស្ត្រជាតិ" ។ការរួមបញ្ចូលគ្នានៃ ontologies ។ ពីទ្រឹស្តីទៅការអនុវត្តជាក់ស្តែង"។

• ការផលិត និងប្រតិបត្តិការនៃផលិតផលស្មុគ្រស្មាញ (វិស្វកម្មមេកានិកធំ ការផលិតប្រេង និងឧស្ម័ន ភាគច្រើនយើងកំពុងនិយាយអំពីស្តង់ដារ ISO 15926);

នា​ពេល​បច្ចុប្បន្ន

នៅទីនេះផងដែរ ហេតុផលគឺភាពស្មុគស្មាញនៃប្រធានបទ នៅពេលដែលឧទាហរណ៍នៅដំណាក់កាលខាងលើ ប្រសិនបើយើងនិយាយអំពីឧស្សាហកម្មប្រេង និងឧស្ម័ន គណនេយ្យសាមញ្ញទាមទារមុខងារ CAD មួយចំនួន។

ក្នុងឆ្នាំ 2008 ព្រឹត្តិការណ៍ដំឡើងតំណាងដែលរៀបចំដោយ Chevron បានកើតឡើង សន្និសិទ.

ទីបំផុត ISO 15926 ហាក់បីដូចជាធ្ងន់បន្តិចចំពោះឧស្សាហកម្មប្រេង និងឧស្ម័ន (ហើយបានរកឃើញថាមានការអនុវត្តកាន់តែច្រើននៅក្នុងវិស្វកម្មមេកានិច)។ មានតែ Statoil (Equinor) ប៉ុណ្ណោះដែលជាប់ពាក់ព័ន្ធជាមួយវា; នៅក្នុងប្រទេសន័រវេសទាំងមូល ប្រព័ន្ធអេកូឡូស៊ី. អ្នកផ្សេងទៀតកំពុងព្យាយាមធ្វើរឿងផ្ទាល់ខ្លួន។ ជាឧទាហរណ៍ យោងតាមពាក្យចចាមអារ៉ាម ក្រសួងថាមពលក្នុងស្រុកមានបំណងបង្កើត "គំរូទស្សនវិជ្ជានៃស្មុគ្រស្មាញឥន្ធនៈ និងថាមពល" ស្រដៀងគ្នាទៅនឹងជាក់ស្តែង។ បង្កើតឡើងសម្រាប់ឧស្សាហកម្មថាមពលអគ្គិសនី.

• អង្គការហិរញ្ញវត្ថុ (សូម្បីតែ XBRL អាចត្រូវបានចាត់ទុកថាជាប្រភេទកូនកាត់នៃ SDMX និង RDF Data Cube ontology);

នា​ពេល​បច្ចុប្បន្ន

នៅដើមឆ្នាំ LinkedIn បានរំខានអ្នកនិពន្ធយ៉ាងសកម្មជាមួយនឹងតំណែងទំនេរពីស្ទើរតែទាំងអស់នៃឧស្សាហកម្មហិរញ្ញវត្ថុដ៏ធំដែលគាត់ស្គាល់ពីរឿងភាគទូរទស្សន៍ "Force Majeure": Goldman Sachs, JPMorgan Chase និង/ឬ Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, Fed, Deutsche Bank... ប្រហែលជាអ្នកគ្រប់គ្នាកំពុងស្វែងរកនរណាម្នាក់ដែលពួកគេអាចផ្ញើទៅ សន្និសីទក្រាហ្វចំណេះដឹង. មួយចំនួនតូចដែលគ្រប់គ្រងដើម្បីស្វែងរក: អង្គការហិរញ្ញវត្ថុបានយកអ្វីគ្រប់យ៉ាង ព្រឹកនៃថ្ងៃដំបូង.

នៅលើ HeadHunter មានតែ Sberbank ប៉ុណ្ណោះដែលបានជួបប្រទះនូវអ្វីដែលគួរឱ្យចាប់អារម្មណ៍ វាគឺអំពី "ការផ្ទុក EAV ជាមួយនឹងគំរូទិន្នន័យដូច RDF" ។

ប្រហែលជាភាពខុសគ្នានៃកម្រិតនៃសេចក្តីស្រឡាញ់ចំពោះបច្ចេកវិទ្យាដែលត្រូវគ្នានៃស្ថាប័នហិរញ្ញវត្ថុក្នុងស្រុក និងលោកខាងលិចគឺដោយសារតែធម្មជាតិឆ្លងជាតិនៃសកម្មភាពក្រោយៗទៀត។ ជាក់ស្តែង ការធ្វើសមាហរណកម្មឆ្លងកាត់ព្រំដែនរដ្ឋទាមទារដំណោះស្រាយរចនាសម្ព័ន្ធ និងបច្ចេកទេសខុសៗគ្នា។

• ប្រព័ន្ធសំណួរ-ចម្លើយជាមួយនឹងកម្មវិធីពាណិជ្ជកម្ម (IBM Watson, Apple Siri, Google Knowledge Graph);

នា​ពេល​បច្ចុប្បន្ន

និយាយអីញ្ចឹង អ្នកបង្កើត Siri គឺ Thomas Gruber គឺជាអ្នកនិពន្ធនៃនិយមន័យនៃ ontology (ក្នុងន័យ IT) ជា "ការបញ្ជាក់ការយល់ឃើញ" ។ តាមគំនិតរបស់ខ្ញុំ ការរៀបចំពាក្យនៅក្នុងនិយមន័យនេះឡើងវិញមិនផ្លាស់ប្តូរអត្ថន័យរបស់វា ដែលប្រហែលជាបង្ហាញថាវាមិនមានទេ។

• ការបោះពុម្ភផ្សាយទិន្នន័យដែលមានរចនាសម្ព័ន្ធ (ជាមួយនឹងហេតុផលធំជាងនេះអាចត្រូវបានសន្មតថាជាទិន្នន័យបើកចំហដែលបានភ្ជាប់) ។

នា​ពេល​បច្ចុប្បន្ន

អ្នកគាំទ្រដ៏ធំនៃទិន្នន័យភ្ជាប់គឺជាអ្វីដែលគេហៅថា GLAM: វិចិត្រសាល បណ្ណាល័យ បណ្ណសារ និងសារមន្ទីរ។ វាគ្រប់គ្រាន់ក្នុងការនិយាយថាបណ្ណាល័យសភាកំពុងលើកកម្ពស់ការជំនួសសម្រាប់ MARC21 BIBFRAME, ដែល ផ្តល់នូវមូលដ្ឋានគ្រឹះសម្រាប់អនាគតនៃការពិពណ៌នាគន្ថនិទ្ទេស ហើយជាការពិតដោយផ្អែកលើ RDF ។

Wikidata ជារឿយៗត្រូវបានលើកឡើងជាឧទាហរណ៍នៃគម្រោងជោគជ័យក្នុងវិស័យ Linked Open Data ដែលជាប្រភេទនៃវិគីភីឌាដែលម៉ាស៊ីនអាចអានបាន ដែលខ្លឹមសារដែលផ្ទុយពី DBPedia មិនត្រូវបានបង្កើតដោយការនាំចូលពីប្រអប់ព័ត៌មានអត្ថបទទេ ប៉ុន្តែជា បានបង្កើតដោយដៃច្រើន ឬតិច (ហើយក្រោយមកក្លាយជាប្រភពនៃព័ត៌មានសម្រាប់ប្រអប់ព័ត៌មានដូចគ្នា)។

យើងក៏សូមណែនាំឱ្យអ្នកពិនិត្យមើលវាផងដែរ។ បញ្ជី អ្នកប្រើប្រាស់នៃការផ្ទុក Stardog RDF នៅលើគេហទំព័រ Stardog នៅក្នុងផ្នែក "អតិថិជន" ។

ក្លាយជានោះដូចដែលវាអាចទៅរួចនៅក្នុង Gartner Hype Cycle for Emerging Technologies 2016 "ការគ្រប់គ្រងពន្ធដារនៃសហគ្រាសនិង Ontology" ត្រូវបានដាក់នៅចំកណ្តាលនៃការធ្លាក់ចូលទៅក្នុងជ្រលងភ្នំនៃការខកចិត្តជាមួយនឹងការរំពឹងទុកនៃការឈានដល់ "ខ្ពង់រាបផលិតភាព" មិនលឿនជាងក្នុងរយៈពេល 10 ឆ្នាំ។

ការភ្ជាប់ទិន្នន័យសហគ្រាស

ការព្យាករណ៍ ការព្យាករណ៍ ការព្យាករណ៍ ...

ក្រៅ​ពី​ចំណាប់អារម្មណ៍​ជា​ប្រវត្តិសាស្ត្រ ខ្ញុំ​បាន​ធ្វើ​តារាង​ខាងក្រោម​ការ​ព្យាករ​របស់ Gartner សម្រាប់​ឆ្នាំ​ផ្សេងៗ​គ្នា​លើ​បច្ចេកវិទ្យា​ដែល​យើង​ចាប់អារម្មណ៍។

ឆ្នាំ	បច្ចេកវិទ្យា	របាយការណ៍	ទីតាំង	ឆ្នាំទៅខ្ពង់រាប
2001	វេបសាយថល	បច្ចេកវិទ្យាកំពុងលេចធ្លោ។	គន្លឹះច្នៃប្រឌិត	5-10
2006	បណ្តាញ Semantic សាជីវកម្ម	បច្ចេកវិទ្យាកំពុងលេចធ្លោ។	កំពូលនៃការរំពឹងទុកអតិផរណា	5-10
2012	វេបសាយថល	ទិន្នន័យ​ធំ	កំពូលនៃការរំពឹងទុកអតិផរណា	> 10
2015	ទិន្នន័យភ្ជាប់	ការវិភាគកម្រិតខ្ពស់ និងវិទ្យាសាស្ត្រទិន្នន័យ	រណ្ដៅនៃការមិនសប្បាយចិត្ត	5-10
2016	ការគ្រប់គ្រងសហគ្រាស Ontology	បច្ចេកវិទ្យាកំពុងលេចធ្លោ។	រណ្ដៅនៃការមិនសប្បាយចិត្ត	> 10
2018	ក្រាហ្វិចចំណេះដឹង	បច្ចេកវិទ្យាកំពុងលេចធ្លោ។	គន្លឹះច្នៃប្រឌិត	5-10

ទោះយ៉ាងណាក៏ដោយនៅក្នុងរួចហើយ "វដ្តនៃការឃោសនាបំផ្លើស ... " 2018 និន្នាការកើនឡើងមួយទៀតបានបង្ហាញខ្លួន - ក្រាហ្វចំណេះដឹង។ ការចាប់បដិសន្ធិឡើងវិញជាក់លាក់មួយបានកើតឡើង៖ ក្រាហ្វ DBMSs ដែលការយកចិត្តទុកដាក់របស់អ្នកប្រើប្រាស់ និងការខិតខំប្រឹងប្រែងរបស់អ្នកអភិវឌ្ឍន៍បានប្រែទៅជាត្រូវបានប្តូរ ក្រោមឥទ្ធិពលនៃសំណើរបស់អតីត និងទម្លាប់នៃអ្នកក្រោយ បានចាប់ផ្តើមចាប់យកវណ្ឌវង្ក និងទីតាំង។ នៃគូប្រជែងជំនាន់មុនរបស់ពួកគេ។

ស្ទើរតែគ្រប់ក្រាហ្វ DBMS ឥឡូវនេះប្រកាសថាខ្លួនជាវេទិកាសមរម្យសម្រាប់ការកសាង "ក្រាហ្វចំណេះដឹង" របស់ក្រុមហ៊ុន ("ទិន្នន័យដែលបានភ្ជាប់" ជួនកាលត្រូវបានជំនួសដោយ "ទិន្នន័យដែលបានតភ្ជាប់") ប៉ុន្តែតើការអះអាងបែបនេះសមហេតុផលប៉ុណ្ណា?

មូលដ្ឋានទិន្នន័យក្រាហ្វនៅតែមានលក្ខណៈ asemantic ទិន្នន័យនៅក្នុងក្រាហ្វ DBMS នៅតែជាទិន្នន័យដដែល។ ការកំណត់អត្តសញ្ញាណខ្សែអក្សរជំនួសឱ្យ URIs ធ្វើឱ្យភារកិច្ចនៃការរួមបញ្ចូលក្រាហ្វ DBMSs ទាំងពីរនៅតែជាកិច្ចការសមាហរណកម្ម ខណៈពេលដែលការរួមបញ្ចូលហាង RDF ពីរជាញឹកញាប់ចុះមកដើម្បីគ្រាន់តែបញ្ចូលគ្នានូវក្រាហ្វ RDF ពីរ។ ទិដ្ឋភាពមួយទៀតនៃ asemanticity គឺការមិនឆ្លុះបញ្ចាំងនៃគំរូក្រាហ្វ LPG ដែលធ្វើឱ្យវាពិបាកក្នុងការគ្រប់គ្រងទិន្នន័យមេតាដោយប្រើវេទិកាដូចគ្នា។

ចុងក្រោយ ក្រាហ្វ DBMSs មិនមានម៉ាស៊ីនសន្និដ្ឋាន ឬម៉ាស៊ីនច្បាប់ទេ។ លទ្ធផលនៃម៉ាស៊ីនបែបនេះអាចផលិតឡើងវិញបានដោយភាពស្មុគស្មាញនៃសំណួរ ប៉ុន្តែវាអាចទៅរួចសូម្បីតែនៅក្នុង SQL ក៏ដោយ។

ទោះជាយ៉ាងណាក៏ដោយប្រព័ន្ធផ្ទុក RDF ឈានមុខគេមិនពិបាកក្នុងការគាំទ្រម៉ូដែល LPG ទេ។ វិធីសាស្រ្តរឹងមាំបំផុតត្រូវបានចាត់ទុកថាជាការស្នើឡើងក្នុងពេលតែមួយនៅក្នុង Blazegraph: គំរូ RDF* រួមបញ្ចូលគ្នារវាង RDF និង LPG ។

ច្រើនទៀត

អ្នកអាចអានបន្ថែមអំពីការគាំទ្រការផ្ទុក RDF សម្រាប់ម៉ូដែល LPG នៅក្នុងអត្ថបទមុននៅលើHabre: "តើមានអ្វីកើតឡើងជាមួយការផ្ទុក RDF ឥឡូវនេះ". ខ្ញុំសង្ឃឹមថាថ្ងៃណាមួយ អត្ថបទដាច់ដោយឡែកមួយនឹងត្រូវបានសរសេរអំពី Knowledge Graphs និង Data Fabric ។ ផ្នែកចុងក្រោយ ដូចដែលងាយយល់ ត្រូវបានសរសេរយ៉ាងប្រញាប់ ទោះជាយ៉ាងណាក៏ដោយ សូម្បីតែប្រាំមួយខែក្រោយមក អ្វីគ្រប់យ៉ាងគឺមិនច្បាស់ជាងនេះជាមួយគំនិតទាំងនេះទេ។

អក្សរសាស្រ្ត

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. ឈើ, ឃ. (ed.) ។ (2011) ការភ្ជាប់ទិន្នន័យសហគ្រាស
5. Keet, M. (2018) ការណែនាំអំពីវិស្វកម្ម Ontology

ប្រភព: www.habr.com