אונטולוגיה¶
האונטולוגיה היא אוצר מילים חי מעל מודל הנתונים שלכם. כל עמודה פיזית ממופה למונח, ועמודות בעלות אותה משמעות חולקות מונח אחד, איך שלא יאייתו אותו. לכל מונח יכולים להיות הגדרה, קשרים מוטפסים למונחים אחרים, רשימת מומחי תוכן ותגיות כמו pii שכל עמודה בעלת אותה משמעות נושאת.
זהו גרף של מושגים, ההגדרות שלהם והקשרים ביניהם. Provisa ממפה אותו לטבלאות ולעמודות שמחזיקות את הערכים, וזה מה שמאפשר לו לענות על שאלות לגבי הנתונים שלכם. מונח הוא טיוטה עד ש-Steward מאשר אותו, והשאלה אם הוא מגיע לנתונים מחושבת מתוך הגרף. האונטולוגיה נפרדת מהמדדים: מונח אומר מהו מושג, מדד אומר איך מחשבים מספר.
אוצר המילים המשותף הזה מחבר את שפת העסק לנתונים הפיזיים. סוכן AI שיודע ש-"customer" מציין כל עמודה שמחזיקה מזהה לקוח לא צריך לנחש איזו מבין cust_id, customerId ו-CUSTOMER_KEY היא הנכונה. כולן ממופות לאותו מונח, והמונח נושא את ההגדרה.
מחלקות, תכונות ומושגים¶
לכל מונח יש בדיוק תפקיד אחד, שנגזר ממה שהוא מעגן. אתם לעולם לא קובעים אותו.
| תפקיד | מעוגן ב- | דוגמה |
|---|---|---|
| מחלקה | טבלה אחת או יותר או תצוגות. המופעים שלה הם השורות שלהן. | customer, שמעגן את customers ואת crm_contacts |
| תכונה | עמודות שאינן מפתחות. | customer email, שמחזיק את customers.email |
| מושג | שום דבר ישירות. הוא מגיע לנתונים דרך הקשרים שלו. | revenue, עם קשתות PART_OF מ-order amount ומ-refund amount |
מונח הוא זה או זה. Provisa מסרב לעגן טבלה על מונח שמחזיק עמודות שאינן מפתח, ומסרב להעביר עמודה שאינה מפתח למונח שמעוגן בטבלאות. כל סירוב מציין את המונח ואת מה שהוא כבר מחזיק.
כל טבלה עם מפתח מציעה מחלקה¶
כששומרים טבלה עם מפתח ראשי, Provisa מעגן אותה במונח מחלקה בטיוטה שנקרא על שם המושג של הטבלה: orders מציעה order, order_lines מציעה order line. טבלאות של אותו מושג חולקות מחלקה אחת. טבלה בלי מפתח ראשי לא יכולה להיות מחלקה, ועיגון שלה נדחה תוך ציון הטבלה.
עיגון שאתם עושים בעצמכם, בממשק, בתצורה או דרך Polly, הוא אצור. הסנכרון לעולם לא מזיז אותו, ועיגון טבלה על מונח אצור מחליף את ההצעה שלה בטיוטה. כשמושג כבר הוא תכונה עם עמודות שאינן מפתח, הטבלאות שלו לא מקבלות הצעה; האונטולוגיה מפרטת אותן במקום זאת תחת לבדיקה.
המפתחות שייכים למחלקה¶
למפתח ראשי אין מונח משלו. כל אחת מהעמודות שלו, כולל החלקים של מפתח מורכב, מציבה את ההפניה שלה על המחלקה של הטבלה שלה.
מפתח זר עובד באותו אופן. כל עמודה בצד "הרבים" של קשר מוצהר מציבה את ההפניה שלה על המחלקה של טבלת היעד, לא משנה איך העמודה נקראת. manager_id ב-employees, שמצביע בחזרה אל employees, נוחת על employee; התפקיד "manager" חי בשם הקשר. עמודה בלי קשר מוצהר היא תכונה, גם כשהשם שלה תואם מחלקה.
Provisa ממקם הפניות של מפתחות בגזירה בלבד, בכל פעם שטבלה מסתנכרנת, קשר משתנה או המחלקה של טבלה משתנה. אי אפשר להזיז עמודת מפתח ידנית, והסירוב מציין את העמודה, את הטבלה שלה ואת המחלקה שלה. עגנו טבלה על מונח אחר והמפתחות שלה עוברים מיד.
אותה ישות בכמה טבלאות¶
מופעים מטבלאות שונות נבדלים זה מזה עד שתאמרו אחרת. כש-customers ו-crm_contacts מתארות שתיהן אותו לקוח, סמנו את הקשר שמחבר ביניהן כאותה ישות. הוא חייב לחבר שתי טבלאות שאותה מחלקה מעגנת, אחד לאחד, על מפתח של כל אחת: המפתח הראשי או אילוץ ייחודיות מוצהר.
כל עוד קיים על טבלה קשר מסוג אותה ישות, אי אפשר לבטל או להחליף את המחלקה שלה. הסירו קודם את הסימון מהקשר.
מחלקה שמעוגנת בכמה טבלאות שקשרי אותה ישות לא מחברים את כולן מסומנת תחת לבדיקה כטבלאות לא מקושרות.
איך נגזרים מונחים¶
Provisa יוצר אוטומטית מונח בטיוטה מכל שם עמודה, לפי כלל נרמול דטרמיניסטי: אחידות אותיות רישיות, פיצול לפי מפרידים ו-camelCase, הרחבת קיצורים והסרת אסימוני ממלא מקום בסוף השם.
הרחבת קיצורים ממפה קיצורים ארגוניים נפוצים לצורתם המלאה: cust → customer, txn → transaction, qty → quantity וכן הלאה. גם id וגם key מורחבים ל-identifier. הטבלה קבועה וזהירה. קיצורים דו-משמעיים כמו st, min ו-no נשארים כפי שהם, כדי שדבר לא ינוחש לא נכון.
הסרת אסימוני ממלא מקום מסירה אסימון סופי identifier, code, index או reference. עמודה בשם cust_id לא מציינת את המזהה עצמו; היא מציינת לקוח דרך ערך חלופי. הסרת ממלא המקום מנחיתה גם את cust_id וגם את customerId על המונח customer. רק אסימונים סופיים מוסרים, ולעולם לא האחרון שנותר, כך שעמודה id לבדה מורחבת ל-identifier ונשארת שם.
ביטול כפילויות הוא המטרה. הכלל דטרמיניסטי, ולכן cust_id, customerId ו-CUSTOMER_KEY מניבים כולם customer. כל עמודה מקבלת הפניה על אותו מונח יחיד, ולאצירה יש מקום אחד להוסיף בו את ההגדרה במקום שלושה.
עמודות מפתח מדלגות על הכלל הזה. ההפניות שלהן הולכות למחלקה, כמתואר למעלה.
ביטויים כלליים¶
חלק מהביטויים המנורמלים כלליים מדי מכדי להיות מושג בפני עצמם. עמודה name, date או identifier לבדה מציינת תכונה של המושג של הטבלה שלה, שאינו קיים מחוץ לטבלה הזאת. לעובדים יש שמות, ולמוצרים יש שמות, אבל הם לא אותו דבר.
כשביטוי נמצא בקבוצה הכללית ויש הקשר טבלה זמין, המונח מקבל הגדרה מדויקת יותר בצורה <table concept> <phrase>: employees.first_name מתנרמל ל-employee first name.
הקבוצה הכללית כוללת שמות עצם של תכונות (name, date, status, type, amount, quantity), ביטויי מעקב ביקורת (created_at, modified_by, submitted_timestamp) ועוד כמה שמופיעים כמעט בכל טבלה.
מונחים הולכים אחרי השם העסקי¶
מונח נגזר הולך אחרי השם העסקי של העמודה: הכינוי שלה כשהמודלר הגדיר כזה, והשם הפיזי שלה אחרת. כש-usr_nm מקבלת את הכינוי user name, המונח הנגזר הוא user name, במקום שבו הרחבת usr_nm הייתה עלולה לתת user number.
מתן כינוי לעמודה הוא התיקון החזק יותר. כינוי מגיע לכל משטח שקורא את העמודה (SQL, GraphQL, סוכני AI, הקטלוג), כך שהמודל מתאר את עצמו נכון בכל מקום. שינוי שם המונח מתקן רשומה אחת בקטלוג ומשאיר את העמודה בשם usr_nm לקורא הבא. באנר הטיוטה בממשק אומר זאת: תנו קודם כינוי לעמודה, ושנו את שם המונח רק כששם העמודה נכון ואוצר המילים לא.
שינוי הכינוי של עמודה גוזר מחדש את המונח שלה בטיוטה, כך שהאונטולוגיה הולכת אחרי המודל ולעולם לא מבקשת את אותו תיקון פעמיים. ברגע שאוצר הוסיף למונח הגדרה, קשר, מומחה או תגית, עריכת כינוי משאירה את העמודה במקומה, כי העבודה הזאת שייכת לאוצר והיא נשארת.
שמות טבלאות של נתיב גישה¶
חלק משמות הטבלאות מתארים נתיב גישה ולא מושג: user_by_name הוא משתמש שמגיעים אליו דרך חיפוש לפי שם, ולא סוג נפרד של ישות. כש-Provisa גוזר את המושג של טבלה, הוא חותך את השם במילת הקישור, כך ש-user_by_name הופך ל-user ו-orders_by_customer הופך ל-order.
בלי החיתוך, user_by_name היה מציע מחלקה user name שמתנגשת עם התכונה האמיתית users.name. החיתוך חל רק על מושגי טבלה. בשם עמודה, by הוא חלק משם העצם המורכב, כך ש-pet_by_name ו-pet_name מתנרמלים לאותו מונח, pet name.
למה אישור ועיגון חשובים¶
סוכנים ואוטומציה אחרת מוצאים את הנתונים שהם עובדים עליהם דרך האונטולוגיה, והם מצטטים אותה. סוכן מתחיל ממונח שאדם אישר. הוא הולך בנתיב למטה אל נתונים שהוא יכול לראות את מהימנותם, מעוגנים או עדיין ממתינים לאישור. הוא מגיע לטבלאות ולעמודות שהוא קורא תחת ההרשאות, כללי השורות והמסכות של התפקיד שלו. לכל צעד בנתיב הזה יש שם שסוכן יכול לשים בציטוט.
לכן שתי עובדות על מונח קובעות מה סוכן יכול לעשות איתו. אנשים קובעים את הסטטוס שלו. Provisa מחשב את העיגון שלו. הדף מציג אותם כשני שבבים נפרדים, ואתם מסננים לפי כל אחד מהם.
סטטוס¶
אדם קובע את הסטטוס של מונח. יש לו אחד בכל פעם.
| סטטוס | משמעות | איך מגיעים אליו |
|---|---|---|
| טיוטה | עדיין לא אושר. | כל מונח נגזר מתחיל כאן, וכך גם כל מונח שאתם יוצרים. |
| מאושר | בחירה של Steward: זה אוצר מילים לעבוד איתו. | Steward מאשר אותו. אישור דורש הגדרה. |
| מיושן | בדרך החוצה. | אוצר מסמן כמיושן מונח מאושר, או שמונח אצור מאבד את העמודה האחרונה שלו. |
| הוצא משימוש | מחוץ לשירות, נשמר כרשומה. | אוצר מוציא אותו משימוש ומציין יורש. |
הגדרה לבדה לא מאשרת דבר. אשרו מונח כשההגדרה שלו אומרת למה העסק מתכוון בו.
עיגון¶
העיגון אומר אם מונח מגיע לנתונים. אף אחד לא קובע אותו: Provisa מחשב אותו מתוך הקשרים של המונח בכל פעם שהגרף משתנה.
העיגון של מונח מסתכל למטה לאורך הנתיבים שלו אל הנתונים. נתיב עובר מהמונח, דרך הקשרים שלו, אל המונח הראשון שמחזיק עמודה או טבלה: המונח בקצה הנתונים, שמחזיק את הקישור. רק המונחים שנמצאים ממש בין שני הקצוות נספרים. המונח עצמו לעולם לא נספר נגד העיגון של עצמו, וגם לא שום דבר מעליו.
| עיגון | סימן | משמעות |
|---|---|---|
| מעוגן | סמל ⏚ ירוק | בנתיב כלשהו למטה אין מונח בטיוטה בין המונח לקצה הנתונים. |
| מעוגן · נתיב ממתין לאישור | סמל ⏚ מעומעם | בכל נתיב למטה יש מונח בטיוטה באמצע. רחפו מעל הסמל: כתוב בו "מגיע לנתונים, אבל רק דרך מונחים שעדיין לא אושרו". |
| לא מעוגן | אין | אף נתיב לא מגיע לנתונים. |
הסמל הוא סמל ההארקה החשמלי. הוא מופיע ברשימת המונחים ליד מספר העמודות, בדף המונח, לפני שם המונח בגרפים ובמקרא הגרף. טקסט הריחוף של מונח מעוגן אומר כמה רחוק הוא מגיע, למשל "מעוגן: מגיע לנתונים ב-3 עמודות"; קורא מסך קורא את אותן מילים.
כמה מקרים נובעים ישירות מהכלל:
- מושג בטיוטה שאתם מנסחים מעל שרשרת מאושרת הוא מעוגן. שבב הסטטוס שלו עדיין אומר טיוטה, והמונחים שמתחתיו לא משתנים.
- מונח שנגזר מעמודה הוא טיוטה בקצה הנתונים. הוא לעולם לא הופך את השרשרת שמעליו לממתינה.
- מונח בטיוטה באמצע הנתיב היחיד הופך כל מונח מעליו ל-⏚ מעומעם. אישור הטיוטה האחת הזאת מעגן אותם.
- נתיב שני נקי מספיק. טיוטה לידו לא משנה דבר.
- מונחים מיושנים ומונחים שהוצאו משימוש שוברים את השרשרת. מונח שהנתיב היחיד שלו עבר דרך אחד כזה מפסיק להיות מעוגן, והשבבים והמסננים שלו אומרים זאת.
מה סוכן רואה¶
חיפוש המונחים של MCP, אוצר המילים של SPARQL וכל משטח אחר המיועד לסוכנים מראים לסוכן את אותו חלק של האונטולוגיה:
- מונח מאושר על נתיב אל נתונים;
- מונח מוגדר בטיוטה על נתיב אל נתונים שמחזיק לפחות מונח מאושר אחד, מסומן כטיוטה;
- מונח לא מוגדר על נתיב כזה רק כצעד אנונימי, בלי שם ובלי הגדרה. כל צעד נשאר נפרד, כך שצורת הנתיב לא משתנה.
שום דבר אחר לא מגיע לסוכן. שרשרת בלי מונח מאושר נשארת מוסתרת, וכך גם מונחים שלא מגיעים לנתונים ומונחים מיושנים או שהוצאו משימוש. אנשים רואים כל מונח בדף האונטולוגיה, עם הסטטוס והעיגון שלו.
כל תוצאת חיפוש נושאת את הסטטוס והעיגון של המונח, את העמודות והטבלאות שלו, את המומחים שלו ואת הנתיבים שלו למטה אל הנתונים. כל צעד בנתיב הוא מונח בעל שם או צעד אנונימי, וקצה הנתונים מפרט למה הוא מקושר. זה הנתיב שסוכן הולך בו ומצטט.
סימון מונח כמיושן¶
סמנו מונח מאושר כמיושן כשהוא בדרך החוצה. אתם נותנים סיבה, שהיא חובה, ובאופן אופציונלי תאריך מתוכנן להוצאה משימוש, היום או מאוחר יותר. בתאריך הזה המתזמן מוציא אותו משימוש. מונח מיושן שובר את השרשרת שעוברת דרכו מהרגע שבו סימנתם אותו, ולכן כדאי לקרוא קודם את תצוגת ההשפעה המקדימה.
מונח שמועד ההוצאה שלו הגיע ועדיין מחזיק עמודות או טבלאות לא יכול לצאת משימוש לפי תאריך, כי רק יורש יכול לקבל אותן. הוא ממתין, ולבדיקה מפרט אותו כהוצאה חסומה עד שתוציאו אותו משימוש עם יורש.
מונח אצור שמאבד את העמודה האחרונה שלו מסומן כמיושן אוטומטית ונשמר. הוא יוצא מהשירות, שומר את התוכן שהעורכים שלו סיפקו, וחוזר אם אותה עמודה מופיעה שוב. מונח לא אצור שלא נותרו לו עמודות מוסר.
הוצאת מונח משימוש¶
הוצאת מונח משימוש מעבירה את כל מה שמחובר אליו ליורש, ואז מוציאה אותו מהשירות.
- העמודות של תכונה עוברות ליורש. הוא חייב להיות תכונה או מושג.
- הטבלאות של מחלקה עוברות ליורש, והמפתחות שלהן עוברים איתן. הוא חייב להיות מחלקה או מושג.
- מושג לא מחזיק דבר, ולכן היורש שלו אופציונלי.
ההוצאה משימוש דורשת סיבה, והיא כותבת קשת REPLACES מהיורש אל המונח שהוצא. המונח שהוצא נשאר כרשומה אינרטית: ההגדרה שלו, התגיות, הקשרים, המומחים והסיבה. הוא לא מוליך דבר. היורש שומר על הסטטוס שלו; הוצאה משימוש לעולם לא מאשרת אותו.
מכיוון שהעמודות שלו שייכות עכשיו ליורש, הלוח של מונח שהוצא משימוש מציג על מה הוא חל לאחרונה: העמודות והטבלאות שלו כפי שהמודל החזיק אותן ב-commit שלפני ההוצאה. הלוח שלו גם מקשר אל המונח שמחליף אותו.
שחזור מונח¶
שחזור מבטל את מה שאוצר קבע. מונח מיושן חוזר להיות מאושר. מונח שהוצא משימוש חוזר כמושג ריק וכטיוטה, מאחר שהעמודות שלו עברו ליורש, וקשת ה-REPLACES שלו מוסרת.
מה הופך מונח לאצור¶
מונח שנולד מנרמול עמודות מתחיל ריק. הוא נעשה אצור כשיש לו אחד מאלה:
- הגדרה שמורה
- קשת קשר
- מומחה תוכן משויך
- תגית, כמו
pii - הוצאה משימוש
מונחים אצורים נשמרים כשהעמודות שלהם עוזבות. הסנכרון לעולם לא גוזר מחדש במקום אחר את העמודות של מונח אצור.
סנכרון מחדש מהטבלאות¶
בכל פעם שטבלה נשמרת או נטענת מחדש, Provisa מיישב את העמודות של הטבלה הזאת מול האונטולוגיה. עמודות חדשות יוצרות או מקשרות מונחים, עמודות שעזבו משחררות את ההפניות שלהן, וכל מונח שנשאר בלי הפניות מוסר או מסומן כמיושן לפי הכלל שלמעלה. עמודות מפתח הולכות למחלקה שלהן, וטבלה עם מפתח בלי מחלקה מציעה אחת.
רק מונחים לא אצורים נגזרים מחדש. אם אתם נותנים כינוי לעמודה והמונח שלה בטיוטה משתנה, העמודה עוברת למונח החדש. אם המונח אצור, העמודה נשארת, כי עריכת כינוי לא גוברת על בחירה של אוצר.
כשהסרת מונח הייתה משאירה מושג בלי נתיב אל הנתונים, Provisa מסמן במקום זאת את המונח הזה כמיושן, כך שהמבנה שבניתם שורד עד שתחברו אותו מחדש.
קשרים¶
מונחים מתקשרים למונחים אחרים באמצעות קשתות מוטפסות.
| סוג | משמעות |
|---|---|
KIND_OF |
מונח המקור הוא סוג של מונח היעד. |
PART_OF |
מונח המקור הוא רכיב של מונח היעד. |
SYNONYM_OF |
שני המונחים ניתנים להחלפה בתחום הזה. |
RELATED_TO |
שני נושאים נפרדים שהולכים יחד, כשאף סוג אחר לא מתאים. הוא שומר מקום ולא מעגן. |
VALID_VALUE_OF |
המקור הוא ערך מותר של מניית היעד או של תחום היעד. |
DERIVED_FROM |
המקור מחושב מהיעד או מגיע ממנו. |
REPLACES |
המקור מחליף את היעד. הוצאת מונח משימוש כותבת אחת כזאת מהיורש שלו. |
PREFERRED_TERM_FOR |
המקור הוא המונח המועדף על פני היעד שאינו מומלץ. |
TRANSLATION_OF |
המקור הוא תרגום של היעד לשפה או לאזור. |
ANTONYM_OF |
המקור הוא ההיפך הסמנטי של היעד. |
קשרים הם בעלי כיוון. הממשק מציג גם קשתות יוצאות (המונח הזה → מונח אחר) וגם קשתות נכנסות (מונח אחר → המונח הזה), ומתייג כל כיוון בביטוי משלו בשפה פשוטה.
הקשתות שמורות בטבלה אסוציאטיבית שמוצהרת כקשר צומת. עמודת סוג הקשר שלה היא המבחין, כך שכל סוג שלמעלה הוא סוג קשר Cypher נפרד בין שני צומתי מונח. שום דבר בזה אינו ייחודי לאונטולוגיה: היא מוצהרת כמו שהייתם מצהירים על צומת מעל הטבלאות שלכם, ואותו קוד קורא אותה.
בניית מילון מונחים שמעגן¶
מונח עוזר לסוכן רק כשהוא מעוגן, כלומר כשנתיב כלשהו של קשרים מוביל ממנו לעמודה או לטבלה. סוכנים רואים רק את המונחים שעל נתיבים כאלה, כפי שמה סוכן רואה מתאר. מונח מעוגן אומר לכם איפה הנתונים שלו נמצאים. מונח לא מעוגן נותן שם לרעיון ומשאיר לכם למצוא את הנתונים בעצמכם.
סוגי הקשרים שאתם בוחרים קובעים אם הנתיב הזה קיים. העיגון זורם ממונח רחב יותר למטה אל מונח צר יותר. revenue מגיע לנתונים כי order amount הוא חלק ממנו ו-order amount מחזיק עמודה. הוא לעולם לא זורם בכיוון ההפוך, ולכן order amount לא מרוויח דבר מכך שהוא חלק מ-revenue.
בדקו כל סוג לפני שאתם בוחרים בו¶
קראו קשת כך: X הוא המונח שממנו היא יוצאת, ו-Y הוא המונח שאליו היא מצביעה. אחר כך הפעילו את הבדיקות בסדר הזה וקחו את הראשונה שעוברת.
| סוג | בדיקה | דוגמה | מה הוא מעגן |
|---|---|---|---|
| סוג של | כל X הוא Y. | כל לקוח ארגוני הוא לקוח. | Y מגיע לנתונים של X. |
| חלק מ | ל-Y יש X. | להזמנה יש סכום הזמנה. | Y מגיע לנתונים של X. |
| ערך תקף עבור | X הוא אחד הערכים המותרים של Y. | פלטינום הוא דרגת לקוח. | Y מגיע לנתונים של X. |
| מילה נרדפת של | X ו-Y פירושם אותו דבר. | קליינט ולקוח. | כל אחד מגיע לנתונים של השני. |
| קשור אל | X ו-Y הם נושאים נפרדים שהולכים יחד, ואף אחד מהם אינו סוג, חלק או ערך של השני. | עוגה ונרות. | כלום. |
נגזר מ, מחליף, מונח מועדף עבור, תרגום של והיפוך של רושמים כל אחד עובדה על שני מונחים. אף אחד מהם לא מעגן.
תכונה שמתארת מושג היא חלק ממנו. תחילת משמרת מתארת משמרת, ולכן היא חלק מ כיסוי משמרות. היא אף פעם לא סתם קשורה אליו.
כשאתם מוסיפים קשר או משנים את הסוג שלו, בורר הסוגים מציג קודם את סוג של, חלק מ וערך תקף עבור, כל אחד עם הבדיקה שלו מתחתיו. קשור אל מופיע אחרון, עם הבדיקה שלו ותזכורת שהוא לא מעגן. הקישור בחירת קשר שמעגן מתחת לבורר פותח את הסעיף הזה.
„קשור אל” שומר מקום¶
קשור אל הוא המוצא האחרון. מכיוון שהוא לא מעגן, מונח שכל הקישורים שלו הם קשור אל לא מגיע לנתונים, לא משנה כמה יש לו. התייחסו לכל אחד כאל ממלא מקום לזוג שעוד לא פתרתם.
כדי לעבור על ממלאי המקום, סמנו קשור אל מעל רשימת המונחים, ליד מיושן ולבדיקה. הרשימה מצטמצמת למונחים שיש להם לפחות קישור קשור אל אחד, בכל אחד מהקצוות. סמל הספר ליד התיבה פותח את הסעיף הזה.
מונח שלא מגיע לנתונים ויש לו רק קישורי קשור אל מציג הערה בדף שלו. ההערה אומרת שייתכן שלזוג חסר מונח ביניים, ומציינת את הצורות שהיו פותרות אותו. זו הכוונה בלבד. שום דבר במונח לא נחסם.
פתרו זוג בעזרת מונח חדש אחד¶
לרוב זוגות הקשור אל חסר מונח ביניים. מונח חדש אחד הופך את ממלא המקום לשתי קשתות שמעגנות, וחמש צורות עושות זאת. הנה הן עבור עוגה ונרות, מהצרה ביותר:
| צורה | מונח חדש | קשתות |
|---|---|---|
| סוג רכיב | קישוט עוגה | נרות סוג של קישוט עוגה; קישוט עוגה חלק מ עוגה |
| התמחות | עוגת יום הולדת | נרות חלק מ עוגת יום הולדת; עוגת יום הולדת סוג של עוגה |
| שלם משותף | מסיבה | עוגה חלק מ מסיבה; נרות חלק מ מסיבה |
| סוג־על משותף | ציוד למסיבה | עוגה סוג של ציוד למסיבה; נרות סוג של ציוד למסיבה |
| מנייה משותפת | סוג פריט למסיבה | עוגה ערך תקף עבור סוג פריט למסיבה; נרות ערך תקף עבור סוג פריט למסיבה |
עקבו אחרי העיגון למטה בכל שורה. בשתי הצורות הראשונות, עוגה מגיעה לנתונים של נרות דרך המונח החדש. בשלוש האחרונות, המונח החדש הוא הקצה הרחב יותר של שתי הקשתות, ולכן הוא מגיע לנתונים של שניהם. לא עוגה ולא נרות מגיעים לנתונים של השני.
לפעמים מונח הביניים כבר קיים, ומספיק לשנות את הסוג של הקישורים. בהדגמת המקלט שמגיעה עם המוצר יש מושג, shift coverage, שמוגדר כחלון הזמן והמקום שבהם איש צוות משובץ לעבודה. החלקים שלו shift start, shift end ו-schedule location מחזיקים כל אחד עמודה. כשהיה מקושר אליהם בקשור אל, shift coverage לא הגיע לנתונים. כשכל אחד מהשלושה מקושר כחלק מ shift coverage, הוא מעוגן דרך שלוש העמודות. זה שלם משותף, והשלם היה שם כל הזמן.
העדיפו את הצורה הצרה ביותר¶
ככל שהמונח החדש רחב יותר, כך העיגון שלו אומר פחות לקורא. מסיבה מחברת עוגה ונרות באותה ודאות כמו קישוט עוגה. אבל צומת רחב כל כך יושב גם מעל רשימת האורחים, המקום והמוזיקה, ולכן העיגון שלו כבר לא אומר אילו נתונים עונים על שאלה על נרות. קישוט עוגה נותן לסוכן נתיב קצר אל העמודות הנכונות. מסיבה נותנת לו נתיב ארוך אל הרבה עמודות.
התחילו מסוג רכיב, ורדו ברשימה רק כשצורה צרה יותר לא מתאימה. השתמשו בסוג־על משותף או במנייה משותפת כשלזוג אין שום דבר צר יותר במשותף.
כשאתם בוחרים „קשור אל”¶
בחירה בקשור אל עבור קישור שאתם מוסיפים פותחת תיבת דו-שיח, למשל "לקשר את נרות ואת עוגה ב„קשור אל”?". שינוי הסוג של קישור קיים לקשור אל פותח אותה גם כן. ההפרעה מכוונת, כי זה הרגע שבו הכי זול לתקן את הקישור.
תיבת הדו-שיח מסבירה קודם למה קשור אל היא הקשת הכי פחות שימושית. היא לא מעגנת, ולכן המונח עדיין לא יכול להגיע לנתונים דרכה. מתחת לזה היא משרטטת את חמש הצורות עבור שני המונחים שלכם, מהצרה ביותר. כל צורה מציגה שם למונח החדש, שהציע מודל ה-AI של הארגון שלכם, למשל נרות → קישוט עוגה → עוגה. אם המודל לא מציע שמות, תיבת הדו-שיח אומרת למה, ואתם מקלידים את השם בעצמכם.
אחר כך אתם בוחרים אחת משלוש פעולות.
- התחלה ליד צורה פותחת את טופס המונח החדש. השם המוצע כבר מולא, וקשרים שנוספים איתו מפרט את שתי הקשתות. שנו את שם המונח, הוסיפו הגדרה ואת התחומים שלו, ואז לחצו על צור. צור מוסיף את המונח. הקשת שנוגעת במונח שאתם עורכים מצטרפת לטופס שלכם ונשמרת איתו. הקשת האחרת נכתבת מיד.
- להוסיף „קשור אל” בכל זאת מוסיף את הקישור בלחיצה אחת. הוא מצטרף לממלאי המקום שהמסנן קשור אל מפרט.
- ביטול לא משנה דבר.
איך עוזר הקשרים בוחר¶
קשרים בתפריט ✨ מבקש ממודל ה-AI של הארגון שלכם קשרים בין כל המונחים שבתחומים שלכם. ההנחיות של המודל כוללות את אותן בדיקות. הוא מעדיף סוג של, חלק מ וערך תקף עבור בכל מקום שאחד מהם מתאים, ומקשר תכונה למושג שהיא מתארת באמצעות חלק מ. הוא מציע קשור אל רק כששני מונחים הולכים יחד בבירור ואף סוג אחר לא מתאים.
העוזר מקשר מונחים שכבר קיימים, ולעולם לא מוסיף מונח. עבור כל קשור אל שהוא מוסיף, הוא מציין מונחים מועמדים לכל צורה שמתאימה. כשהוא מסיים, קישורי „קשור אל” לבדיקה מפרט כל אחד מהזוגות האלה עם הצורות שלו, מהצרה ביותר, ואת המועמדים לכל אחת. לחצו על אחד משני המונחים כדי לפתוח אותו. אם זוג צריך מונח חדש, ואיך לקרוא לו, זו ההחלטה שלכם.
מדדו את מילון המונחים¶
הדוח Ontology quality מודד את מילון המונחים מתוך המודל, לפי תחום ולפי Steward. פתחו אותו במציג הדוחות. הוא מדווח על:
- החלק של המונחים בשירות שהם מעוגנים, כשמונחים מעוגנים לגמרי ומונחים שממתינים לאישור נספרים בנפרד;
- החלק של המונחים המאושרים והמעוגנים, כלומר המונחים שסוכן רשאי להשתמש בהם;
- ממלאי מקום שלא נפתרו, כלומר קישורי קשור אל ומונחים שכל הקישורים שלהם הם קשור אל;
- דיוק העיגון, כמספר הצעדים מכל מונח אל הנתונים וכמספר הנתיבים שעוברים דרך מונח צומת רחב;
- מונחים שמעוגנים רק דרך טיוטות, כל אחד עם המונח שאישורו היה מעגן אותו לגמרי;
- מונחים לא מוגדרים על נתיבים אל נתונים;
- סחיפה, המונחים שאיבדו או קיבלו עיגון מאז התקופה הקודמת.
כל שורה מקשרת אל המונח שלה, וכל שורת ממלא מקום מקשרת אל קישורי הקשור אל של המונח הזה, לבדיקה. כמו כל דוח, הוא נקרא דרך הצינור המנוהל תחת התפקיד שלכם, ואפשר לייצא אותו.
מושגים¶
למושג אין עמודות או טבלאות משלו. השתמשו במושג לרעיון עסקי שמשתרע על כמה מונחים מוחשיים, ואז חברו אותו למונחים שכן מחזיקים נתונים. revenue, למשל, יכול להיות מושג, עם קשתות PART_OF מ-order amount, adjustment amount ו-refund amount.
מושג שלא יכול להגיע לאף עמודה או טבלה דרך גרף הקשרים לא מציין נתונים. הוא לא מופיע בחיפוש המונחים של סוכנים או בייצוא המטא-נתונים, ולבדיקה מפרט אותו כאין נתונים. תחומים חלים רק על מושג. כל מונח אחר מקבל את התחומים שלו מהטבלאות שהוא מעגן או מהעמודות שהוא מחזיק.
PII לפי משמעות¶
PII הוא מאפיין של מה שעמודה משמעה, ולכן Provisa מאפשר לכם לסמן אותו פעם אחת, על המונח, ומכסה כל עמודה בעלת המשמעות הזאת, כולל עמודות שיירשמו בהמשך.
התגית pii מוצבת על עמודה או על מונח תכונה, לעולם לא על מקור, טבלה, מחלקה או מושג. מונח חייב להיות מוגדר ולא מוצא משימוש כדי לקבל אותה. סימון מונח בטיוטה נדחה עם "הגדירו את המונח כדי לסמן אותו", ואי אפשר לנקות את ההגדרה של מונח מתויג עד שמסירים את הסימון.
כל עמודה של מונח מתויג נושאת pii, ואיתה sensitive, בכל מקום שבו קוראים תגיות: ממשל, מיסוך, רגישות, ייצוא ותצוגות התגיות. שום דבר לא מועתק לעמודות. עמודה שמועברת אל המונח נושאת את התגית מיד, ועמודה שמועברת ממנו כבר לא. כל עמודה אומרת מאיפה התגית שלה מגיעה: הוצבה על העמודה, עם הסיבה, או דרך מונח, שהיא מציינת.
כשאתם מסמנים עמודה שהמונח שלה הוא תכונה, הממשק שואל אם לסמן גם את העמודות האחרות שמשמען אותו דבר.
- כן מציב את התגית על המונח.
- רק את זו מסמן את העמודה לבדה, ושואל למה.
עמודה שהיא PII דרך המונח שלה לא ניתנת להסרת סימון בפני עצמה. הסירו את הסימון מהמונח, או העבירו את העמודה למונח שתואם את מה שהיא מחזיקה.
העברות שמאבדות תגיות¶
העברת עמודה למונח אחר יכולה להסיר ממנה תגית: העברת customers.email מ-customer email (מתויג pii) למונח לא מתויג הייתה משאירה את עמודת הדוא"ל בלי הגנה. כל העברה שאדם מבצע נבדקת מראש. זה כולל תביעה או העברה של עמודה, הוצאת מונח משימוש, ושמירה או מחיקה של קשר שמשייך מחדש עמודות מפתח.
כשעמודה הייתה מפסיקה לשאת pii לגמרי, ההעברה נדחית עד שתחליטו. הממשק מציג סיכום אחד של מה שכל עמודה מועברת מאבדת ומרוויחה, ההפסדים קודם.
- העבר ממשיך, כשכל תגית שאבדה מאושרת.
- העבר וסמן מעביר את התגיות שאבדו אל המונח שאליו העמודות עוברות, באותו שינוי.
- ביטול לא מעביר דבר.
עמודה ששומרת על התגית דרך הסימון שלה עצמה לא צריכה אישור. העברות שהמודל מבצע בעצמו, כמו גזירה מחדש של העמודות של טיוטה, לעולם לא משנות תגית שעוברת בירושה.
לבדיקה¶
האונטולוגיה מדווחת על מה שדורש את תשומת לבכם כממצאים. מונח עם ממצא כלשהו הוא לבדיקה, ורשימת המונחים מסננת לפי זה. טיוטה רגילה אינה ממצא; טיוטות הן המצב הרגיל של האונטולוגיה. מונח שמגיע לנתונים רק דרך טיוטות הוא ממצא, כי אישור אחד היה מציב אותו מול סוכנים.
| ממצא | מה הוא אומר | התיקון |
|---|---|---|
| טבלאות לא מקושרות | מחלקה מעגנת כמה טבלאות שקשרי אותה ישות לא מחברים את כולן. | סמנו קשרי אותה ישות ביניהן. |
| מחלקה ותכונה | מחלקה מחזיקה עמודות שאינן המפתחות שלה, או שלטבלה עם מפתח אין מחלקה כי המושג שלה הוא תכונה. | העבירו את העמודות לתכונה, או עגנו מחדש את הטבלה. |
| תגית על סוג שגוי | מונח שאינו תכונה נושא תגית שרק תכונה מעבירה לעמודות. | הסירו את התגית. |
| הוצאה חסומה | מונח מיושן עבר את התאריך המתוכנן להוצאתו אבל עדיין מחזיק עמודות או טבלאות. | הוציאו אותו משימוש עם יורש. |
| אין נתונים | מושג בטיוטה לא מגיע לנתונים. | קשרו אותו למונח שמחזיק נתונים. |
| מאושר, לא מעוגן | מונח מאושר לא מגיע לנתונים, ולכן אף סוכן לא רואה אותו. | קשרו אותו למונח שמחזיק נתונים. |
| מעוגן · נתיב ממתין לאישור | כל נתיב למטה אל הנתונים עובר דרך טיוטה. הממצא מציין את הטיוטה שאישורה מעגן את המונח. | פתחו את המונח הזה ואשרו אותו. |
ממצאים מדווחים; הם לא משנים דבר עד שאתם פועלים.
ייצוא מטא-נתונים¶
האונטולוגיה מתפרסמת לקטלוגי נתונים חיצוניים כחלק מייצוא המטא-נתונים. מונחים מאושרים מתפרסמים, כל אחד עם העיגון שלו: grounded, grounded_pending או not_grounded. טיוטה לעולם לא יוצאת מ-Provisa. העיגון לייצוא נשפט לפי העמודות והטבלאות שבפועל מתפרסמות. מונח שכל העמודות שלו נמנעות מהייצוא, כי הטבלאות שלהן אינן מוצרי נתונים או כי מסננים טכניים מחריגים אותן, נמנע יחד איתן.
מונח מאושר שאוצר סימן מאז כמיושן מתפרסם עם הסטטוס, הסיבה והתאריך המתוכנן להוצאתו, כך שכל קטלוג יכול למפות אותו לסמן היישון שלו.
קשתות קשר מתפרסמות רק כששני מונחי הקצה מתפרסמים. נכסי עמודות מיוצאים באופן עצמאי, ולכן החרגת מונח לא מסתירה את הנתונים שמתחתיו.
החרגת מונח מהייצוא¶
חלק מהעמודות נושאות צנרת, כמו מזהי אצוות ETL, גרסאות שורה וחותמות זמן של קליטה. מונח שנגזר מעמודה כזאת יכול להיות בעל הגדרה מדויקת ועדיין לא להיות אוצר מילים עסקי. הפקד החרג מייצוא מטא-נתונים מונע את המונח, וכל קשת קשר שמסתיימת בו, מהקטלוגים ש-Provisa מפרסם אליהם. העמודות עצמן עדיין מיוצאות כנכסים.
מה שקובע הוא אם העסק משתמש במילה. למזהה אצוות ETL יש משמעות ברורה ששייכת לאונטולוגיה בשביל המהנדסים, אבל לא לקטלוג עסקי ליד customer ו-revenue.
עבודה עם האונטולוגיה¶
פתחו את אונטולוגיה בסרגל הניווט. הלוח השמאלי מפרט כל מונח עם התפקיד שלו, הסטטוס שלו אלא אם הוא מאושר, ושבב העיגון שלו. המסננים סטטוס ועיגון מצמצמים את הרשימה לפי כל אחד, התיבה מיושן מציגה או מסתירה מונחים מיושנים, לבדיקה מצמצם אותה למונחים עם ממצאים, וקשור אל מצמצם אותה למונחים עם קישור קשור אל. לחצו על מונח כדי לפתוח את הלוח שלו.
הלוח מציג זה לצד זה את התפקיד, הסטטוס והעיגון של המונח, ועבור תכונה את סימון ה-PII שלה עם מספר העמודות שהוא מכסה. מונח ⏚ מעומעם מציין את הטיוטות שאישורן היה מעגן אותו. מונח מיושן או שהוצא משימוש מציג מי שינה את הסטטוס שלו ולמה. מונח עם ממצאים נפתח עם סעיף לבדיקה: לחצו על ממצא כדי לראות מה נמצא ואת הפעולה שמתקנת אותו.
סיכום ניהול¶
כשאין מונח פתוח, הלוח מציג את סיכום הניהול. הוא מפרט את המונחים שסוכנים יכולים לראות, את מונחי ה-⏚ המעומעמים שכל אחד מהם ממתין לאישור אחד, עם המונח שיש לאשר, ואת המונחים המאושרים שלא מגיעים לנתונים. אשר טיוטות מוגדרות ומעוגנות מפרט כל טיוטה שיש לה הגדרה והיא מעוגנת; בטלו את הסימון של כל טיוטה שההגדרה שלה לא נכונה, ואשרו את השאר יחד. כפתור הלוח בכותרת מחזיר את הסיכום.
לראות קודם את ההשפעה¶
אישור, הוצאה משימוש וקישור של מונח משנים כל אחד מה מגיע לנתונים. לפני כל אחד מהם, הדף מציג מה הפעולה הייתה משנה: כמה מונחים הופכים למעוגנים, ל-⏚ מעומעמים או ללא מעוגנים, ולכמה טבלאות סוכנים מרוויחים או מאבדים נתיב. למשל, "אישור region מעגן 3 מונחים ונותן לסוכנים נתיב אל 2 טבלאות נוספות". אישור פותח את התצוגה המקדימה עם כפתור האישור שלה, הוצא משימוש מציג אותה מתחת ליורש שאתם בוחרים, ועיגון טבלה בטופס העריכה מציג אותה מתחת לטבלה לפני שאתם שומרים.
עריכה פותחת את המונח כולו כטופס אחד. השמירה מחילה את כל השינויים יחד.
- שנו את שם המונח כדי לשנות את הניסוח שלו בלי להזיז את העמודות שלו.
- הוסיפו הגדרה בהקלדה, או לחצו על כפתור טיוטת ה-AI כדי ליצור נקודת התחלה משם המונח, מהעמודות שלו ומהקשרים שלו. הטיוטה לא נשמרת עד שאתם שומרים את הטופס.
- תבעו עמודות כדי להעביר עמודות ממונחים אחרים אל המונח הזה, או בחרו העבר למונח ליד אחת העמודות שלו. כל עמודה שייכת למונח אחד. עמודות מפתח הולכות אחרי המחלקה שלהן ואי אפשר להעביר אותן.
- עגנו טבלאות על מחלקה, או הסירו אותן.
- סמנו PII על תכונה.
- הוסיפו קשר, ובחרו את הסוג שלו. שנו את הסוג של קשת קיימת במקום, במקום למחוק ולהוסיף אותה מחדש.
- שייכו מומחים לפי מזהה משתמש, כ-
expertאו כ-author.
ליד עריכה, הלוח מציע את פעולות הסטטוס שהמונח מאפשר: אישור של טיוטה מוגדרת, סמן כמיושן למונח מאושר, הוצא משימוש לכל מונח בשירות, ושחזור למונח מיושן או שהוצא משימוש.
מתפריט ✨, הגדרות ממלא כל הגדרה ריקה במעבר אחד ולעולם לא דורס טקסט של אדם. קשרים מוסיף קשתות מוטפסות על פני רשימת המונחים; הצעות שמציינות מונחים לא מוכרים, את אותו מונח פעמיים או סוג לא מוכר נזרקות. כל קשור אל שהוא מוסיף מופיע ברשימה לבדיקה, כפי שאיך עוזר הקשרים בוחר מתאר.
באנר טיוטה על מונח אומר לכם אם הוא עדיין צריך הגדרה (תנו כינוי לעמודה או הוסיפו הגדרה) או רק את האישור שלכם. באנר נפרד אומר מתי מונח לא מגיע לנתונים: קשרו אותו למונח שיש לו נתונים.
שאילתות על האונטולוגיה¶
האונטולוגיה היא סכימה שאפשר לתשאל, בשם ontology, לצד הסכימה meta שמתארת את מבנה המודל. הטבלאות שלה מתחילות בקו תחתון, כך שהטבלה של מחלקה לעולם לא חולקת שם עם אחת מהן.
| טבלה | שורה אחת לכל |
|---|---|
_terms |
מונח, עם הסטטוס שלו, העיגון שלו, ההגדרה שלו והאם הוא מחלקה, תכונה או שניהם |
_term_refs |
קישור של תכונה לעמודה, עם הטבלה והתחום של העמודה |
_term_edges |
קשר בין שני מונחים |
_domains |
תחום שמונח שייך אליו |
_experts |
מומחה או כותב שמשויך למונח |
_axioms |
היגד של האונטולוגיה ב-RDFS, ב-OWL וב-SKOS |
_closure |
מונח בזוג עם כל מונח שהוא סוג שלו, בכל עומק, ועם עצמו |
קישור מחבר מונח לעמודה בסכימה meta, כך שאפשר לצרף את ontology._term_refs אל meta.table_columns ואל meta.registered_tables. הטבלאות של האונטולוגיה הן לקריאה בלבד. הן משתנות כשאתם אוצרים מונחים.
אתם קוראים מונח רק כשאתם מגיעים לאחד התחומים שלו. מונח בלי תחום גלוי לכולם, וכך גם מונח ארגוני (*). קשר או אקסיומה גלויים כששני המונחים שלהם גלויים.
האונטולוגיה ב-SPARQL¶
SPARQL מחזיר את האונטולוגיה באוצרות המילים הסטנדרטיים, כך שכלי RDF קורא אותה כמו כל אונטולוגיית OWL:
- מחלקה היא
owl:Class, וקשר סוג-של בין מחלקות הואrdfs:subClassOf; - תכונה היא
owl:DatatypeProperty, אוowl:ObjectPropertyכשכל עמודה שהיא מקשרת היא מפתח לטבלה עם מחלקה; - ה-
rdfs:domainשל תכונה הוא המחלקה של כל טבלה שהיא מקשרת ממנה עמודה, וה-rdfs:rangeשלה הוא המחלקה שהמפתחות שלה מובילים אליה או טיפוס ה-XML Schema של העמודות שלה; - קשר סוג-של בין תכונות הוא
rdfs:subPropertyOf; - לכל מונח השם שלו הוא
skos:prefLabelוההגדרה שלו היאskos:definition.
מונח נקרא לפי ה-IRI של אוצר המילים שלו, <your Provisa address>/vocab/term/<name>, ה-IRI שמטפס את השורות של הטבלאות שהוא מעגן. מונח שהוצא משימוש לא קובע דבר.
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?class ?parent ?label WHERE {
?class a owl:Class ; rdfs:subClassOf ?parent .
?parent skos:prefLabel ?label .
}
שאילתה יכולה לצרף את האונטולוגיה לשורות שאתם קוראים. המופעים של מחלקה כוללים את אלה של כל מחלקה שהיא סוג שלה, בכל עומק:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX term: <https://your-provisa/vocab/term/>
SELECT ?party ?class WHERE {
?party a ?class .
?class rdfs:subClassOf* term:Party .
}
תכונה עובדת באותו אופן: ?x ?p ?v . ?p rdfs:subPropertyOf* term:amount קורא את הערכים של כל תכונה שהיא סוג של amount. אתם מקבלים את המופעים של הטבלאות שאתם קוראים, כך שמחלקה שאי אפשר לקרוא את הטבלאות שלה לא מוסיפה אף מופע.
אותם היגדים הם שורות של ontology._axioms ב-SQL, וזוגות סוג-של, סגורים בכל עומק, הם שורות של ontology._closure. GraphQL, Cypher ושאר שפות השאילתה לא מציעות את שתי הטבלאות האלה.
ראו גם¶
- ייצוא מטא-נתונים מסביר איך מונחים וקשרים מתפרסמים לקטלוגי נתונים חיצוניים.
- שושלת ברמת עמודה מסביר את סייר השושלת ואיך עמודה פיזית מדווחת על המונחים שמקושרים אליה.
סכימת האונטולוגיה¶
סכימת המערכת ontology הופכת את אוצר המילים לניתן לתשאול מ-SQL, GraphQL, Cypher, REST ו-MCP, אותם משטחים שבהם אתם משתמשים לנתונים שלכם. היא נמצאת לצד meta, שמחזיקה את מבנה המודל; ontology מחזיקה את המשמעות שלו.
שני חלקים מרכיבים את הסכימה: תצוגות הגדרה וטבלאות מחלקה.
תצוגות הגדרה¶
חמש תצוגות חושפות את התוכן של מילון המונחים:
| תצוגה | תוכן |
|---|---|
_terms |
כל מונח: השם, התפקיד (מחלקה, תכונה, מושג), ההגדרה, הסטטוס והעיגון שלו. |
_term_refs |
כל קישור של מונח לעמודה: שם המונח, המקור, הטבלה והעמודה. |
_term_edges |
כל קשת קשר: מונח מקור, סוג קשת ומונח יעד. |
_domains |
חברות בתחומים: שם המונח וכל תחום שהוא שייך אליו. |
_experts |
שיוכי מומחים: שם המונח, מזהה המשתמש והתפקיד (expert או author). |
תצוגה שישית, _axioms, מחזיקה כל שלשת RDFS/OWL/SKOS שהסכימה יכולה לבטא, שורה אחת לכל שלשה, עם העמודות subject, predicate, object, object_iri ו-object_literal. object מציין את האובייקט כשהוא מונח; object_iri מחזיק אותו כשהוא IRI, ו-object_literal כשהוא ליטרל. אחת משלוש העמודות מחזיקה את הערך בכל שורה. כלים שמעדיפים שלשות על פני שורות טבלאיות קוראים מכאן.
קישור מונח, כלומר מונח שמקושר לעמודה ונרשם ב-_term_refs, שונה מקישור פקודה. קישור מונח אומר מה עמודה משמעה; קישור פקודה מחבר פונקציה לצינור השאילתות.
טבלאות מחלקה¶
כל מונח מחלקה שלא הוצא משימוש הופך לתצוגה בסכימה ontology שנקראת על שם המונח, עם קווים תחתונים במקום רווחים. מחלקה שמעוגנת בטבלה אחת מניבה תצוגה אחת; מחלקה שמעוגנת בכמה טבלאות מניבה את האיחוד של הטבלאות האלה.
בתצוגת איחוד מופיעות השורות של כל טבלת מקור. העמודה _source_table מזהה מאיזו טבלה הגיעה כל שורה: היא מחזיקה את השם המלא של הטבלה, domain.table. עמודת תכונה שטבלת מקור לא מקשרת היא NULL בשורות שלה. תכונה שמקושרת לכמה עמודות של אותה טבלה הופכת לעמודת מערך.
כל עמודה בתצוגת מחלקה מתאימה לתכונה מקושרת. התצוגה מנוהלת דרך אותו צינור כמו כל קריאה אחרת.
דוגמה. מחלקה customer שמעוגנת ב-sales.customers וב-crm.contacts, עם תכונה name שמקושרת ל-customers.name ול-contacts.full_name, ותכונה segment שמקושרת רק ל-customers.segment:
-- rows from both tables; segment is NULL for crm.contacts rows
SELECT _source_table, name, segment
FROM ontology.customer
WHERE segment = 'enterprise';
הרשאות קריאה¶
אותם כללי ממשל שחלים על הטבלאות שלכם חלים כאן.
מונח מופיע בתצוגות ההגדרה רק אם אתם מגיעים לפחות לאחד התחומים שלו. מונח בלי תחום גלוי לכולם. שורת קישור מופיעה רק כשהעמודה שלה מוגשת לכם. קשת מופיעה רק כששני המונחים שלה גלויים לכם. עמודת תכונה בתצוגת מחלקה מופיעה רק כשהעמודות שמתחתיה מוגשות.
לא צריך גישה מיוחדת. אם אתם יכולים לתשאל טבלה, אתם יכולים לתשאל את מונחי המחלקה שמעוגנים בה.
SPARQL¶
נקודת הקצה של SPARQL מגישה את הסכימה ontology כאונטולוגיית RDFS/OWL/SKOS סטנדרטית. כל מונח מחלקה הופך ל-owl:Class, כל קשת סוג-של הופכת ל-rdfs:subClassOf, כל מונח תכונה הופך ל-owl:DatatypeProperty או ל-owl:ObjectProperty עם rdfs:domain ו-rdfs:range, קשתות תת-תכונה הופכות ל-rdfs:subPropertyOf, שמות הופכים ל-skos:prefLabel והגדרות ל-skos:definition. אותן הרשאות קריאה חלות.
ה-IRI הבסיסי של כל המונחים נגזר מההגדרה server.public_url, תחת הנתיב /vocab/term/. למונח מחלקה בשם customer יש ה-IRI {public_url}/vocab/term/customer.
שלוש שאילתות שאונטולוג היה כותב:
מצאו את כל תת-הסוגים של Party, בכל עומק:
PREFIX : <{public_url}/vocab/term/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?c WHERE {
?c rdfs:subClassOf* :Party .
}
מצאו לקוחות עם ערך פלח, בעזרת ה-IRI של המונח:
פרטו את כל התכונות שהוצהרו על Customer עם הטווחים שלהן:
PREFIX : <{public_url}/vocab/term/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?p ?range WHERE {
?p rdfs:domain :Customer ;
rdfs:range ?range .
}
החליפו את {public_url} בכתובת הציבורית של הפריסה שלכם, כפי שהוגדרה ב-server.public_url.