การพัฒนา Ontology 101 คู่มือการสร้าง First Ontology

1. ทำไมต้องพัฒนา ontology ในปีที่ผ่านมาการพัฒนา ontology มี ข้อกำหนดของข้อตกลง อย่างเป็นทางการใน (Gruber 1993) โดยมี ย้ายจากขอบเขตของ Artificial Intelligence laboratories บน desktops ของผู้เชี่ยวชาญ ออนโทโลจีถูกวางบน World - Wide Web ซึ่ง ออนโทโลจีจากเว็บนั้น อยู่ในช่วงที่เป็น taxonomies ที่ใหญ่โดยจัด หมวดหมู่เป็นเว็บไซต์ ( เช่นใน Yahoo!) เพื่อ categorizations ของ ผลิตภัณฑ์สำหรับการขาย และบอกคุณสมบัติ ( เช่นที่ Amazon.com)

WWW Consortium (W3C) เป็น การ พัฒนาทรัพยากร Description Framework (Brickley และ Guha 1999), ภาษาสำหรับ การเข้ารหัสความรู้ บนเว็บเพจเพื่อให้เข้าใจเพื่อค้นหา ตัวแทนอิเล็กทรอนิกส์ สำหรับข้อมูล Defense Advanced Research Projects Agency (DARPA) ร่วมกับ W3C ที่จะ พัฒนา DARPA Agent Markup Language (DAML) โดย ขยาย RDF กับแสดงออกต่อโครงสร้าง วัตถุประสงค์เพื่ออำนวยความสะดวกใน การติดต่อตัวแทน Web (Hendler และ 2000 McGuinness) หลายสาขา

ขณะนี้การพัฒนาออนโทโลจีมาตรฐาน ที่ ผู้เชี่ยวชาญโดเมน สามารถใช้ร่วมกันและอธิบายข้อมูลใน ฟิลด์ของ ยาสำหรับ เช่นมีการผลิตขนาดใหญ่มาตรฐาน คำศัพท์โครงสร้างเช่น SNOMED ( ราคาและ Spackman 2000) และ เครือข่ายความหมายของ ระบบ Unified Medical Language ( และ Lindberg 1993)

วัตถุประสงค์ทั่วไปที่เกิดขึ้นใหม่ ตัวอย่างเช่น United Nations Development Program และ Dun & Bradstreet รวมความพยายามที่จะ พัฒนา ontology UNSPSC ซึ่งมี คำศัพท์สำหรับผลิตภัณฑ์และ บริการ ontology กำหนดคำศัพท์ทั่วไปสำหรับ นักวิจัยที่ต้องการใช้ข้อมูลในโดเมน มัน มีความหมายเกี่ยวกับ machine-interpretable ของแนวคิด พื้นฐานในโดเมนและ ความสัมพันธ์ของพวกเขา

ทำไมคนที่ต้องการจะพัฒนา ontology ความเข้าใจร่วมกันในการร่วมกันของ โครงสร้างของข้อมูลของประชาชนหรือ ตัวแทนซอฟต์แวร์ การใช้ความรู้นำมาใช้ใหม่ของโดเมน ในการทำสมมติฐานโดเมนชัดเจน ให้ความรู้โดเมนแยกจากความรู้การ ปฏิบัติงาน ในการวิเคราะห์โดเมนความรู้

การแบ่งปันความเข้าใจร่วมกันของ โครงสร้างของข้อมูลของประชาชนหรือ ซอฟต์แวร์ตัวแทนเป็นหนึ่งในเป้าหมาย ทั่วไปในการพัฒนาออนโทโลจี (Musen 1992; Gruber 1993) ตัวอย่างเช่นสมมติว่าหลายเว็บไซต์ต่างมี ข้อมูลทางการแพทย์หรือให้บริการอี คอมเมิร์ซทางการแพทย์ หากเว็บไซต์ เหล่านี้ร่วมกันและเผยแพร่ ontology เดียวกัน อ้างอิงคำที่พวกเขาใช้ทั้ง หมดแล้วคอมพิวเตอร์สามารถสกัดและ รวมตัวแทนข้อมูลจากเว็บไซต์ต่างๆ เหล่านี้ ทำให้ตัวแทนนี้สามารถใช้ข้อมูล การตอบแบบสอบถามผู้ใช้หรือข้อมูล เข้าโปรแกรมอื่นๆได้

การเปิดใช้ความรู้โดเมนเป็นหนึ่งในแรง ขับเคลื่อนที่อยู่ เบื้องหลัง surge ล่าสุดในการวิจัย ontology เช่นรุ่นของหลายโดเมนที่ต้องเป็น ตัวแทนของแนวคิดของ เวลา ซึ่งรวมถึง notions ของช่วงเวลา, จุดในเวลา มาตรการสัมพันธ์ของเวลาและอื่นๆ

หากกลุ่มนักวิจัยพัฒนา ontology ใน รายละเอียดอื่น ๆก็สามารถนำมาใช้ ใหม่ได้สำหรับโดเมน นอกจากนี้หาก เราจำเป็นต้องสร้าง ontology ขนาด ใหญ่เรา สามารถรวมหลายออนโทโลจีที่มีอยู่ อธิบายบางส่วนของ โดเมนขนาดใหญ่ ทั้งนี้เรายังสามารถ นำ ontology ทั่วไปมาใช้ใหม่ เช่น ontology UNSPSC เพื่ออธิบายโดเมนของเราที่น่าสนใจ

ontology ของโดเมนไม่มีเป้าหมายใน ตัวเอง ดังนั้นการพัฒนา ontology คือคล้ายกับกำหนดชุดของ ข้อมูลและโครงสร้าง ของโปรแกรมอื่นใช้ วิธีการแก้ปัญหา, การใช้งานโดเมน อิสระและตัวแทนซอฟต์แวร์โดยใช้ออน โทโลจีและ ฐานความรู้สร้างจากออนโทโลจีเป็น ข้อมูล

2. อะไรอยู่ใน ontology? Artificial - Intelligence มีความหมาย หลาย ontology เพื่อวัตถุประสงค์ใน การแนะนำ ontology นี้เป็นคำอธิบาย แนวคิดในโดเมนของวาทกรรม โดย คุณสมบัติของแนวคิดการอธิบาย คุณสมบัติและคุณลักษณะต่างๆของ แนวคิด ร่วมกับชุดของกรณีแต่ละ ลำดับชั้นถือว่าฐานความรู้ ในความเป็น จริงมีเส้นที่ปลาย ontology และ ฐานความรู้เริ่มต้น

ในด้านการปฏิบัติพัฒนา ontology ประกอบด้วย - กำหนดการเรียนรู้ใน ontology - การจัดลำดับชั้นในอนุกรมวิธาน (superclass – subclass) - ช่องการกำหนดและอธิบายได้ค่า สำหรับช่องนี้ - กรอกค่าสำหรับช่องสำหรับแต่ละกรณี

เราสามารถสร้างฐานความรู้โดยกำหนด กรณีของแต่ละ ลำดับชั้นเหล่านี้โดยกรอกสล็อตข้อมูล เฉพาะค่าและข้อจำกัด สล็อตเพิ่มเติม

3. วิธี Knowledge Engineering – Simple ที่เรากล่าวว่าก่อนหน้านี้ไม่มีวิธีการใด วิธีการหนึ่งที่ถูกต้อง หรือที่เราคุยเรื่องทั่วไปในพิจารณาและ เสนอกระบวนการ หนึ่งที่เป็นไปได้ในการพัฒนา ontology เราอธิบายวิธีการ ทบทวนการพัฒนา ontology ดังนี้ เรา เริ่มต้นด้วย pass แรกที่ ontology จากนั้นเราจะแก้ไขและ ปรับแต่ง ontology และ กรอกข้อมูลในรายละเอียดต่างๆ

ที่เรากล่าวว่าก่อนหน้านี้ไม่มีวิธีการใด วิธีการหนึ่งที่ถูกต้อง หรือที่เราคุยเรื่องทั่วไปในพิจารณาและ เสนอกระบวนการ หนึ่งที่เป็นไปได้ในการพัฒนา ontology เราอธิบายวิธี การทบทวนการพัฒนา ontology ดังนี้ เราเริ่มต้นด้วย pass แรกที่ ontology จากนั้นเราจะ แก้ไขและ ปรับแต่ง ontology และกรอกข้อมูลใน รายละเอียด ต่างๆ

เราคุยแบบจำลองการตัดสินใจที่นัก ออกแบบต้องการให้เป็น รวมทั้ง pros cons,, และผลการแก้ไข ปัญหาที่แตกต่างกัน อันดับแรกเราต้องการเน้นกฎพื้นฐานใน การออกแบบบาง ontology ที่เราจะดูหลายครั้ง กฎเหล่านี้ อาจดูเหมือนไม่มี เหตุผลมากกว่า พวกเขาสามารถช่วย ตัดสินใจการออกแบบ ในหลายกรณี

1) ไม่มีวิธีใดวิธีหนึ่งที่ถูกต้องในแบบ โดเมนอยู่เสมอที่เลือกทำงานได้ ทางออกที่ดีที่สุดมักจะขึ้นอยู่กับ โปรแกรมประยุกต์ 2) การพัฒนา Ontology คือจำเป็นต้อง ดำเนินการซ้ำ 3) แนวคิดใน ontology ควรจะใกล้เคียง กับวัตถุ (physical หรือ logical) และความสัมพันธ์ในโดเมนของคุณที่ น่าสนใจ เหล่านี้มักจะเป็นคำนาม ( วัตถุ ) หรือกริยา ( ความสัมพันธ์ ) ใน ประโยคที่อธิบายโดเมนของคุณ

นั่นคือสิ่งที่เราตัดสินใจจะใช้สำหรับ ontology และวิธีการรายละเอียดหรือ ontology ทั่วไปที่เป็นไปได้จะ แนะนำหลายแบบจำลองการตัดสินใจ ระหว่างการทำงานได้ หลายทางเลือกเราจะต้องตรวจสอบว่า จะทำงานได้ดีขึ้น

เรายังต้องจำไว้ว่า ontology เป็นรูปแบบ ของความเป็นจริงของ โลกและแนวคิดใน ontology ต้องสะท้อน ความเป็นจริงนี้ หลังจากที่เรากำหนดรุ่นแรกของ ontology เราสามารถ ประเมินผลและแก้ปัญหาโดยใช้ในการใช้ งานหรือวิธีการ แก้ปัญหาหรืออภิปรายกับผู้เชี่ยวชาญ หรือทั้งสองอย่าง ดังนั้นเราจะต้องแก้ไข ontology แรก กระบวนการออกแบบซ้ำ นี้อาจจะต่อผ่านทั้งวงจรชีวิตของ ontology

ขั้นตอนที่ 1 การตรวจสอบโดเมนและ ขอบเขตของ ontology ขั้นตอนที่ 2 พิจารณาการนำกลับมาใช้ ใหม่ของ ontology ที่มีอยู่ ขั้นตอนที่ 3 ความสำคัญของการแจก แจง ontology ขั้นตอนที่ 4 การกำหนดชั้นเรียนและ ลำดับชั้น ขั้นตอนที่ 5 กำหนดคุณสมบัติของชั้น slots ขั้นตอนที่ 6 กำหนดปัญหาของ slot ขั้นตอนที่ 7. สร้าง instances

4. Defining classes และ class hierarchy ส่วนนี้จะอธิบายสิ่งที่ระวังและ ข้อผิดพลาดที่ง่ายต่อการทำ เมื่อกำหนดเรียนและลำดับชั้น (4 ขั้นตอนจากข้อ 3) ที่เราได้ กล่าวก่อนที่จะมีไม่มีลำดับชั้นเดียวที่ ถูกต้องสำหรับโดเมนใด ก็ตาม ลำดับชั้นขึ้นอยู่กับใช้เป็นไปได้ ของ ontology

5. Defining properties— รายละเอียด เพิ่มเติม ส่วนนี้จะบอกรายละเอียดหลายทราบเมื่อ กำหนด ontology เราจะพูดถึง inverse slots และ default values สำหรับ slot 5.1 Inverse slots คือ ค่าของ slot อาจ ขึ้นอยู่กับค่าของช่องอื่น 5.2 Default values คือ ระบบจะระบุค่า เริ่มต้น ค่านั้นจะเป็น กรณีส่วนใหญ่ของ class นั้นๆ เราสามารถ กำหนดค่านี้เป็น ค่าเริ่มต้นสำหรับ slot ได้ เราสามารถเปลี่ยน ค่าเป็นค่าอื่น ๆ ที่ facets

6. ชื่อ การกำหนดชื่อข้อตกลงสำหรับแนวคิด ใน ontology เป็นไป ตามหลักการณืเหล่านี้ ทำให้ ontology เข้าใจได้ง่าย และยัง ช่วยหลีกเลี่ยงข้อผิดพลาด แต่เรา จำเป็นต้อง กำหนดชื่อ สำหรับคลาสและ slot แล้วปฎิบัติตามนั้น

6.1 พิมพ์ใหญ่และตัวคั่น ลำดับแรก เราสามารถปรับปรุงการอ่าน ของ ontology หากเราใช้อักษร ตัวพิมพ์ใหญ่สำหรับชื่อสอดคล้อง แนวคิด เราใช้ Space ในแกนแยกคำ แต่ถ้าใช้ คำร่วมกันจะได้คำใหม่ เช่น MealCourse ใช้ underscore หรือ ขีด หรือตัวคั่นอื่น ๆ ในชื่อ Meal_Course

6.2 เอกพจน์และพหูพจน์ ชื่อคลาสเป็นชุดของออปเจค ตัวอย่างเช่น คลาสไวน์เป็นจริง ทั้งหมด แต่สิ่งที่เลือกก็ควรจะ สอดคล้อง ontology และระบบ บางระบบได้กำหนดให้ผู้ใช้เพื่อแจ้ง ล่วงหน้าว่าจะใช้เป็น เอกพจน์หรือพหูพจน์

6.3 คำนำหน้าและคำต่อท้าย บาง knowledge - base วิธีการแนะนำให้ ใช้คำนำหน้าและคำต่อท้าย ในชื่อที่ แตกต่างระหว่างคลาส และ slot สอง คำสั่งพื้นฐานจะ has- เพิ่ม หรือต่อท้าย ชื่อจะได้ has-maker และ has-winery และในช่อง maker-of และ winery-of 6.4 พิจารณาการตั้งชื่ออื่น ข้อมูลเพิ่มเติมที่ควรพิจารณาเมื่อมีการ กำหนดตั้งชื่อ

7. ทรัพยากรอื่นๆ เราใช้เป็น Protégé ontology พัฒนาสิ่งแวดล้อมสำหรับตัวอย่างของ เรา Duineveld และเพื่อนร่วมงาน (Duineveld 2000) อธิบายและ เปรียบเทียบจำนวน ontology พัฒนาสภาพแวดล้อมอื่นๆ เราได้ พยายามที่อยู่พื้นฐานของการพัฒนา มาก ontology และยังไม่ได้กล่าวถึง หลายเรื่องขั้นสูงหรือวิธีการอื่นในการ พัฒนา ontology

8. บทสรุป ในคู่มือนี้ได้อธิบายวิธีการ ontology พัฒนาระบบตามที่ ประกาศ เราอยู่ขั้นตอนใน กระบวนการพัฒนา ontology และ ปัญหาที่ซับซ้อนของการกำหนดลำดับ ชั้นเรียนและ คุณสมบัติของคลาสและ instances อย่างไรก็ตามหลังจากนี้กฎ และคำแนะนำ ในสิ่งที่สำคัญที่สุดที่จะ จำได้ดังต่อไปนี้ไม่มี ontology สำหรับโดเมนใดๆ

การออกแบบ Ontology เป็นกระบวนการ ที่สร้างสรรค์และ ไม่มีการออกแบบของสอง Ontology โดยคนอื่นที่เหมือนกัน โปรแกรมศักยภาพของ ontology และ ความเข้าใจของนัก ออกแบบและมุมมองของโดเมนที่ต้อง สงสัยจะมีผลต่อการ เลือกออกแบบ ontology“The proof is in the pudding”- เรา สามารถประเมินคุณภาพของ ontology ของเราเท่านั้นโดยใช้ ในงานที่เราออกแบบนั้น