چکیده
این مقاله به تجزیه و تحلیل شباهتها و تفاوتهای بین انتولوژی یا هستیشناسی (که تمرکزش روی معناست)، و طرح پایگاهداده یا بانک اطلاعاتی (که تمرکزش روی داده است) میپردازد. ما پرسشهایی را در مورد هدف، بازنمایی، ایجاد، کاربرد آنها، و حوزه معنایی هر یک از این دو مورد مطرح میکنیم. بیستوپنج ویژگی مربوط به این دو ساختار بازنمایی را تبیین مینماییم. هر کدام دارای بخش معنایی توانمندی، با استفاده از منطق صوری (رمزی) برای ایجاد مدلهای مفهومی در موضوع اصلی است. درحالیکه که تفاوتهایی در 90% این خصوصیات وجود دارد، این تفاوتها اساسا تاریخی و نه فنی هستند. همچنین به تعریف مزایا و معایب هر یک از این دو مورد میپردازیم و به این مورد توجه میکنیم که معمولا هیچ چیزی، ساده بدست نمیآید. مشکلاتی که فکر میکنید از دست آنها خلاص شدهاید، ممکن است در جای دیگر به شکلی متفاوت و غیرقابل پیشبینی نمایان گردند. بحث ما به این نکته نزدیک میشود که چگونه انتولوژی، سهمی در یکپارپگی دادههای سازمانی دارد، افزایش استفاده از URI ها (شناسه منبع جهانی) به عنوان شناسههای جهانی (برای مثال در زبان OWL )، به طور قابل توجهی باعث افزایش یکپارچهسازی داده و همچنین اشتراک و بکارگیری مجدد الگو میگردد. تمرکز اصلی روی معنا، به انتولوژی کمک میکند تا از پیچیدگیهای غیرضروری در پایگاههایداده سنتی بزرگ اجاتناب گردد، و اساسا باعث سادهسازی فرایند یکپارچگی میگردد. انتولوژی به عنوان کورسوی امیدی در تاریکی، جهت یکپارچهسازی دادههای بزرگ سازمانی، است.
1. مقدمه
ما سوالاتی را که معمولا پرسیده میشود، مورد ارزیابی قرار مدادیم که عبارتند از: تفاوت بین طرح انتولوژی و پایگاه داده (بانک اطلاعاتی) چیست؟ این مقاله موضوعات محاورهای را، با تمرکز روی مسائل عملیاتی و کارکردگرا نسبت به ارائه دیدگاههای نظری گسترده در حوزه موضوعات رسمی، مد نظر قرار میدهد. چون این موضوعات به عنوان فراگیرترین مباحث هستند، تمرکز خود را اکثرا روی الگوی رابطهای قرار میدهیم. بعضی از توضیحات ما، و نه همه آنها دارای کارکردی فراتر از مدل رابطهای است، به ترتیبی که روشهای زیادی برای تشخیص الگو و نمایش دادهها وجود دارد. دو الگوی JSON و XML ، فراگیر هستند. همچنین پایگاههای داده استقرایی، پایگاههای داده شیءگرا، و پایگاههای داده نموداری (گراف) وجود دارد.
7.3 یکپارچهسازی داده و سازمان
در پایان، نقش مهمی را که انتولوژی در یکپارچهسازی داده و سازمان ایفا میکند، بیان میکنیم. یکپارچگی داده/ قابلیت همکاری به عنوان نیاز مبرمی در اکثر سازمانها است. یکی از دلایل آن اینست که هر برنامه کاربردی، از پایگاه داده مربوط به خود استفاده میکند، حتی زمانیکه این برنامههای کاربردی، فعالیتهای مشابهی انجام میدهند. همچنین اکثر پایگاههای داده در هر زمان شرکتی را نشان میدهد که از طریق کسب سود کار میکند. موانع مختلفی برای یکپارچهسازی پایگاههای داده وجود دارد:
1. فقدان شناسههای منحصربه فرد چهانی که تمام سیستمها و پایگاههای داده را در یک سازمان تحت پوشش قرار میدهد.
2. مقدار کار مورد نیاز برای دستیابی به مفهوم الگو، به دلیل پدیده معناشناسی به سهولت دسترسپذیر نیست. اما به دلیل .....
Abstract
This paper analyzes the similarities and differences between an ontology (focused on meaning), and a database schema (focused on data). We address questions about purpose, representation, creation, usage and semantics of each. We distill out twenty-five features that characterize these two representational artifacts, the majority of which are relevant to both. Each has a strong semantic heritage using formal logic to build conceptual models of some subject matter. And while there are differences in 90% of the features, the differences are mostly historical, not technical. We identify pros and cons for each, and notice that there is usually no free lunch. The disadvantage that you think you are getting rid of may show up elsewhere in a different and unexpected way. We close by considering how ontology contributes to enterprise data integration. The emergence of using URIs as global identifiers (e.g. in OWL) dramatically enhances data integration as well as schema reuse and sharing. The primary focus on meaning helps ontology break through a lot of unnecessary complexity that exists in large traditional databases and greatly simplifies the process of integration. Ontology is providing a glimmer of light at the end of the tunnel for enterprise-wide data integration. Keywords: Ontology, schema, database schema, conceptual model, logical schema, physical schema, triple store, relational database, data integration Accepted by: Leo Obrst
1. Introduction
We address the frequently asked question: what is the difference between an ontology and a database schema? This paper adopts a conversational perspective focusing on operational and pragmatic issues rather than attempting to offer deep theoretical insights into formal matters. Because they are by far the most prevalent, we will focus mostly on relational schema. Some but not all of our remarks will apply beyond the relational model, where there are many ways to specify schema and represent data. JSON an XML schema are popular. There are also deductive databases object-oriented databases and graph databases.
7.3. Data and enterprise integration
In closing, we note the important role that ontology plays in data and enterprise integration. Data integration/interoperability is a pressing need in most organizations. One reason for this, is that each application uses its own database, even when the applications are doing similar things. Also, more databases show up each time a company grows by acquisition. There are various barriers to integrating databases:
1. The lack of globally unique identifiers that span all the systems and databases in an organization.
2. The amount of work it takes to find out what the schema means, largely due to the semantics not being readily available, but also due to . . .
چکیده
1. مقدمه
2. کاربرد این مقایسه چیست؟
2.1 هدف
2.2 نمونهها و دادهها
2.3 طرح XML
3. این مقایسه چطور به نظر میرسد؟
3.1 نشانهگذاری
3.2 بیانگری
3.3 الگوی XML
4. چگونه میتوان همچنین مقایسهای را انجام داد؟
4.1 کاربرد مجدد یا اغاز از ابتدا؟
4.2 استانداردسازی
4.3 الگوی XML
5. چگونه این مقایسهها پیادهسازی و مورد استفاده قرار میگیرد؟
5.1 تغییر مدیریت، چالاکی و انعطافپذیری
5.2 موتورهای پردازش
5.3 قابلیت اجرا
5.4 عملکرد
5.5 الگوی XML
6. حوزههای معنایی در چه جایی قرار دارند؟
6.1 الگوی XML
7. خلاصه و نتیجهگیری
7.1 خلاصه مطلالب براساس شمارهبندی
7.2 مشاهدات کلیدی
7.3 یکپارچهسازی داده و سازمان
Abstract
1. Introduction
2. What is it for?
2.1. Purpose
2.2. Instances and data
2.3. XML schema
3. What does it look like?
3.1. Notation
3.2. Expressivity
3.3. XML schema
4. How do you build one?
4.1. Reuse or start from scratch?
4.2. Normalization
4.3. XML schema
5. How is it implemented and used?
5.1. Change management, agility and flexibility
5.2. Processing engines
5.3. Executability
5.4. Performance
5.5. XML schema
6. Where are the semantics?
6.1. XML schema
7. Summary and conclusion
7.1. Summary by the numbers
7.2. Key observations
7.3. Data and enterprise integration