RDF, ट्रिपल, और हर रोज क्षुधा

Question

अस्पष्ट, बेख़बर सवालों में अर्थ वेब:

1: क्यों एप्लिकेशन डेवलपर, एप्लिकेशन विकास समुदायों और साहित्य (किताबें, ट्यूटोरियल, आदि) के लगभग 100% है कि के लिए दी गई लेना आप या तो एक रिलेशनल डेटाबेस या एक कुंजी-मूल्य स्टोर का उपयोग कर डेटा व्यक्त करना चाहते हैं?

2: सभी "ट्रिपल" डेटा संरचनाओं का उपयोग क्यों नहीं कर रहे हैं?

3: क्या त्रिभुज डेटाबेस और कुंजी-मूल्य भंडार से संबंधित हर समस्या पर लागू नहीं होते हैं, और कम से कम हर मामले में काम करने में आसान नहीं हैं?

Answer 1

1. अधिकांश डेवलपर रिलेशनल डेटाबेस और/या कुंजी/मान भंडार क्योंकि वे अच्छी तरह से ज्ञात रहे हैं, व्यापक रूप से सिखाया आसानी से उपलब्ध है, और सबसे डेवलपर्स करने के बारे में क्या परवाह के सबसे करने के लिए पर्याप्त का उपयोग करें।
2. अधिकांश डेवलपर्स कुछ विशेष उद्देश्यों (और यहां तक ​​कि उत्तरार्द्ध कुछ असामान्य है) के अलावा (संभवतः) को छोड़कर ट्रिपल का उपयोग करने के लिए बहुत कम (यदि कोई है) कारण देखते हैं।
3. नहीं - ट्रिपल विशेष रूप से उपयोग करने में आसान नहीं होते हैं जब अधिकांश लोग उन्हें समझ नहीं पाते हैं या उनका उपयोग कैसे करते हैं। यहां तक ​​कि उन डेवलपर्स जो उन्हें समझते हैं, वे आमतौर पर जो भी प्रदान करते हैं उसके बारे में परवाह नहीं करते हैं।

आम तौर पर, मुझे लगता है कि काफी कुछ डेवलपर्स जल्दी से जो सोच है RDF, उल्लू, SKOS, ontologies, तर्क इंजन, आदि के अंतर-उलझ गड़बड़ किसी के लिए में खो: "लेकिन मैं सिर्फ उपयोगकर्ता की चाहते हैं ऑर्डर इतिहास "(या जो भी हो), यह सब कुछ लेने में थोड़ा सा है, साथ सौदा करें,

Answer 2

ट्रिपल किसी भी अन्य डेटा संरचना का प्रतिनिधित्व कर सकते हैं। लेकिन यह जरूरी नहीं है कि उन्हें काम करना आसान हो। यदि आपकी समस्या तालिका के आकार का है, तो एक तालिका डेटा संरचना बेहतर काम करेगी। ग्राफ़ डेटा स्ट्रक्चर के साथ, आपको ट्रिपल से टेबल बनाने के बारे में सोचना होगा, और यह अतिरिक्त काम है।

अधिकांश समस्याओं को हल करना (विशेष रूप से सरल समस्याएं जहां आपके डेटा का आकार अनुमानित है) को ग्राफ़ डेटा संरचना की लचीलापन की आवश्यकता नहीं होती है।

Answer 3

मैंने खुद से पहले एक ही सवाल पूछा है। आम तौर पर लोग समस्या के रूप में जटिलता का हवाला देते हैं। यह वास्तव में एक बुरी आदत है, क्योंकि जितना अधिक हम समस्या छोड़ते हैं, उतना ही बुरा होगा। अर्थात् वेब एक जटिल समस्या का एक परिष्कृत समाधान है। यह कोई आसान नहीं मिलता है। मुझे लगता है कि आरडीबीएमएस को सादगी की तुलना करना मूर्खतापूर्ण है। अधिकांश डेवलपर्स आजकल ओआरएम से परिचित हैं और सारणीबद्ध दृढ़ता के साथ काम करते हैं, कुछ को दृढ़ता तंत्र के बारे में कभी पता नहीं है। अर्थात् वेब (ओआरडीएफएम) के लिए दृढ़ता ढांचे आमतौर पर परिष्कृत या विकसित नहीं होते हैं। ऐसा कहकर, बहुत सारे संगठन आरडीबीएमएस से दूर जा रहे हैं और नोएसक्यूएल समाधान में निवेश कर रहे हैं, जिनमें से आरडीएफ और एसपीएआरक्यूएल मेरी राय में सर्वश्रेष्ठ उम्मीदवार हैं।

एक महान मामले का अध्ययन मैं हमेशा का कहना है कि जब लोग अर्थ वेब जटिल करने के लिए किया जा रहा है के बारे में बात बार्ट वैन ल्युवेन कहानी है:

http://semtechbizsf2012.semanticweb.com/sessionPop.cfm?confid=65&proposalid=4590

तो एक वास्तविक पूरा समय फायर फाइटर (जो वास्तविक आग डालता है) एक वास्तविक समस्या (आपातकालीन सेवा में डेटा पहुंच) को हल करने के लिए डेटाबेस और मालिकाना प्रारूपों के स्थान पर SPARQL और RDF का उपयोग कर सकते हैं, फिर हमारे बाकी के लिए थोड़ा बहाना नहीं है। मेरा मुद्दा यह है कि यह तकनीक नहीं है जो बाधा है, यह कुछ और है।