Engineering Applications of Artificial Intelligence

1. Engineering Applications of Artificial Intelligence

2. เว็บเชิงความหมาย (Semantic Web) คือส่วนขยายของเว็บปัจจุบันเพื่อทำให้การใช้ข้อมูลบนเว็บสามารถนำมารียูสได้ และเอื้อต่อเครื่องจักรในการคิวรีอย่างเป็นอัตโนมัติ ในปัจจุบัน ข้อมูลที่ได้ถูกจัดทำขึ้นในเว็บเป็นข้อมูลที่มีประโยชน์แต่ไม่เอื้อต่อเครื่องจักรในการวิเคราะห์หรือคิวรีอย่างอัตโนมัติเนื่องจากข้อมูลเหล่านั้นขาดโครงสร้างและเป็นเพียงชิ้นส่วนของเท็กซ์ (Text) ซึ่งมนุษย์สามารถเข้าใจความหมาย แต่เครื่องจักรไม่สามารถเข้าใจความหมายได้

3.  ในปี ค.ศ. 2001 นายทิม เบอร์เนอร์ ลี บิดาผู้ให้กำเนิดเว็บได้นำเสนอหลักการเว็บเชิงความหมาย หรือ Semantic Web (W3C, 2001) ซึ่งมีวัตถุประสงค์ที่จะทำให้ข้อมูลบนเว็บเป็นข้อมูลที่มีประโยชน์ สามารถนำไปวิเคราะห์ รียูส (Reuse) เพื่อใช้งานในแอพพลิเคชั่นต่าง ๆ และเอื้อต่อเครื่องจักรสามารถสืบค้นได้อย่างอัตโนมัติ ตั้งแต่นั้นเป็นต้นมาเว็บเชิงความหมายได้เป็นหัวข้อที่นักวิจัยได้ให้ความสนใจเป็นอย่างมาก และถูกนำไปประยุกต์ใช้กับหลาย ๆ เทคโนโลยี เช่น กริด (GRID) และ เว็บเซอร์วิส (Web services) โดยมีวัตถุประสงค์ที่จะทำให้การทำงานในเทคโนโลยีเหล่านั้นมีประสิทธิภาพมากขึ้น 

4. โครงสร้างของเทคโนโลยีเว็บเชิงความหมายสามารถแสดงได้ดังภาพ โครงสร้างของเทคโนโลยีเว็บเชิงความหมายสามารถแสดงได้ดังภาพ 

5. ซึ่งมีองค์ประกอบต่าง ๆ ได้แก่ มาตรฐานการอ้างอิงรีซอร์ส ภาษาที่ใช้ในการอธิบายข้อมูลเชิงความหมาย  เช่น ภาษา XML และ XML Schema , RDF และ RDF Schema ภาษา Ontology เช่น ภาษา OWL  ภาษา RDF  เป็นภาษาที่ใช้กำหนดโครงสร้างของข้อมูลซึ่งสามารถอธิบายความสัมพันธ์ขององค์ประกอบต่าง ๆ ที่บรรยายในเอกสารในรูปแบบของประโยค (Statement) ซึ่งมีโครงสร้างประกอบด้วยซับเจกต์ (Subject) รีเลชั่น (relation)  และ อ็อบเจกต์(object)  

6. ภาษาออนโทโลจี (Ontology Lanuage) เป็นภาษาที่ใช้ในการกำหนดคำศัพท์ (vocabulary) และคุณสมบัติ (Property) ต่าง ๆ   สำหรับการอธิบายคอนเซ็ปต์ (Concept) ซึ่งคอนเซ็ปต์ คือสิ่งต่าง ๆ ที่กำลังถูกบรรยายในโดเมนหนึ่ง ๆ       ออนโทโลจี (ontology) เป็นข้อกำหนด (Specification) สำหรับอธิบายคอนเซ็ปต์ในโดเมนหนึ่ง ๆ เพื่อให้ทุกคนในโดเมนนั้นสามารถเข้าใจในความหมายของสิ่งเหล่านั้นในทางเดียวกัน ซึ่งข้อมูลที่อธิบายในออนโทโลจีแสดงข้อเท็จจริง (Fact) ของการปรากฎของสิ่งเหล่านั้นในโดเมน และอาจแสดงความรู้ (Knowledge) ซึ่งได้จากการอนุมานออนโทโลจี (Ontology Reasoning) โดยใช้ข้อเท็จจริงที่มีอยู่ 

7. ข้อมูลต่าง ๆ ที่บรรยายในเว็บเชิงความหมายอาจพิจารณาได้ว่าเป็นภาษาเชิงโลจิกอย่างหนึ่ง และการพิจารณาหาความหมายที่แท้จริงของข้อมูลที่ได้บรรยายนั้น จำเป็นที่จะต้องใช้กฎเป็นส่วนหนึ่งในการอนุมานออนโทโลจี (Ontology Reasoning) เพื่อค้นหาความรู้ใหม่ (New Knowledge) ระดับชั้นโลจิกในสแตกของเว็บเชิงความหมายจึงครอบคลุมกฎ (Rule) และอาจรวมไปถึงภาษาเชิงโลจิกบางอย่างที่นำมาใช้ในการอนุมานออนโทโลจี กล่าวคือข้อมูลที่ถูกบรรยายโดยภาษาออนโทโลจี อาจถูกเปลี่ยนรูปให้อยู่ในภาษาเชิงโลจิกภาษาใดภาษาหนึ่ง เพื่อใช้ในขบวนการอนุมานออนโทโลจี  

8. พรูฟ (Proof) เป็นการพิสูจน์ว่าข้อมูลเชิงความหมายที่ได้บรรยายในเว็บเชิงความหมายนั้น มีความน่าเชื่อถือได้หรือไม่ ในการพิสูจน์อาจจะใช้กฎต่าง ๆ ในขบวนการพิสูจน์ก็ได้   ข้อมูลต่าง ๆ ในเว็บเชิงความหมาย ถือว่าเป็นข้อมูลที่สามารถเผยแพร่ได้อย่างเปิดเผยในระบบเว็บ ซึ่งเอื้อต่อเครื่องจักรในการคิวรี ดังนั้นในสแตกของเว็บเชิงความหมายจึงได้กำหนดการรักษาความปลอดภัยของข้อมูลให้กับข้อมูลที่ถูกอธิบาย เช่น เอกสาร RDF เอกสารออนโทโลจี หรือส่วนหนึ่งส่วนใดของข้อมูลในเอกสารเหล่านั้นอาจมีการเข้ารหัสเพื่อสร้างความปลอดภัยในการใช้งาน

10. Steps on development of systems based on Semantic Web Services ขั้นตอนในการพัฒนาตามแบบ semantci web service แสดงให้เห็นถึงกระบวนการที่เกี่ยวข้องกับการพัฒนาของระบบตามแบบ SWS ขั้นตอนของกระบวนการนี้จะถูกนำเสนอดังนี้

11. 1.Domain specification (ข้อกำหนดโดเมน) โดเมนที่ระบุไว้อย่างเป็นทางการผ่าน Ontology ซึ่ง Ontology เหล่านี้มีวัตถุประสงค์เพื่อระบุแนวคิดและความสัมพันธ์กล่าวคือนักพัฒนาควรใช้วิธีการที่จะ พัฒนาOntologyเหล่านี้ ซึ่งได้นำเสนอวิธีการบางอย่างเพื่อกำหนดวิธีการสำหรับสร้าง Ontology ตามแบบ SWSคือไม่จำเป็นต้องละเอียดถี่ถ้วนหรือเฉพาะเจาะจง

12. 2.Service specification (ข้อกำหนดการบริการ) จากข้อกำหนดในขั้นตอนก่อนหน้านี้ การบริการมีหน้าที่รับผิดชอบในการให้บริการระบบฟังก์ชันการทำงานที่กำหนดไว้ในขั้นตอนนี้กระบวนการของระบบถูกใช้ในการให้ข้อมูลที่จำเป็นเพื่อดำเนินการค้นพบโดยใช้ การวางแผน

13. 3.Services development (การพัฒนาการให้บริการ) ในขั้นตอนนี้ผู้บริโภคสามารถค้นหาข้อมูลที่มีอยู่แล้วสำหรับการให้บริการ ซึ่งก็คือ สามรถลดเวลาการดำเนินงาน ซึ่งมีสองแนวทางในการนำข้อมูลที่มีอยู่แล้วมาใช้ ตามรูปแบบของ SWS คือ 3.1 ข้อมูลการบริการโดยไม่ได้อธิบายความหมาย: เนื่องจากไม่มีการอธิบายความหมายสำหรับการให้บริการผู้พัฒนาจะต้องสร้าง รายละเอียดของความหมายของข้อมูลการบริการจับคู่บริการ และนำไปหารูปแบบ service ontology เอง 3.2 ข้อมูลการบริการที่มีคำอธบายความหมายมาให้อยู่แล้ว

14. 4.Definitions of services repository (คำจำกัดกัดของที่เก็บข้อมูลการบริการ) เนื่องจากระบบการบริการได้ถูกอธิบายและพัฒนาไว้แล้ว ผู้พัฒนาควรกำหนดชนิดของพื่นที่เก็บข้อมูลการให้บริการด้วย 5.Development of discovery mechanisms (การพัฒนากลไกการค้นพบ) ผู้พัฒนาได้อิมพลีเมนท์หรือเลือกกลไกสำหรับ service discovery และ automatic service composition กลไกการสืบค้น

15. มีหน้าที่ต่อการจัดการบริการเพื่อตรวจสอบซึ่ง service จะทำการทำงานแบบไดนามิคตลอดที่ผู้ใช้ยังใช้งานอยู่ มันสำคัญต่อการบ่งชี้ว่า เซอร์วิสที่ถูกเลือกการกลไกการค้นพบไม่จำเป็นต้องได้รับการพัฒนาใน Services Development step. เมื่อ intelligent systems พัฒนาอย่างต่อเนื่องการบริการใหม่ๆได้ถูกเพิ่มเข้ามา และทางเลือกสำหรับการบริการนี้จะสามารถเพิ่มประสิทธิภาพให้แก่ระบบได้ ตัวอย่างอื่นเช่นเพิ่มลงที่เก็บข้อมูล เพื่อลดความซ้ำซ้อน.ในกรณีของการ error ระหว่าง execute ใน service ทั่วไป , กลไกการค้นพบต้องค้นหาการให้บริการที่เหมือนกันเจอโดยอัตโนมัติ โดยที่ไม่ต้องติดต่อผู้พัฒนาโดยตรง

16. 6.Development of invocation mechanisms (การพัฒนากลไกการร้องขอ) กลไกการร้องขอต้องถูกพัฒนาเพื่อเรียกร้องบริการที่เลือก โดยกลไกที่ค้นพบนี้จะต้องยืนยันได้ว่า ผู้ใช้สามารถใช้งานได้จริง 7.Technologies integration (การรวบรวมเทคโนโลยี) ขั้นตอนนี้จะเป็นผู้รับผิดชอบสำหรับรวบรวมเครื่องมือที่ใช้ในการจัดการบริการที่จำเป็น

17. GRINV เป็นซอฟท์แวร์ที่ทำหน้าที่เป็นสื่อกลางระหว่างผู้ใช้กับ แอปพลิเคชั่น หรือระหว่างโปรแกรมต่างๆ เป็น Middleware ที่มีจุดมุ่งหมายคือ การค้นพบ การร้องขออัตโนมัติต่อ Semantic Web Service Grinv ยังให้พื้นที่เก็บข้อมูลของบริการที่มีวัตถุประสงค์เพื่อ ลดปัญหาประสิทธิภาพการทำงานที่พบในการโหลดของ Ontology นอกจากนี้ Grinv ยังสามารถรวบรวมเทคโนโลยีของพื้นที่การให้บริการ

23. provider requester registry provider registry registry

24. พัฒนาการการบริการ ในขั้นตอนนี้การดำเนินการของบริการที่สร้างขึ้น ในขั้นตอนที่เกิดขึ้นก่อนหน้าบทความที่กล่างถึงการพัฒนาการของบริการในรูป 6 ดังนั้น เรื่องของกรณีการใช้งานแต่ละบริการต่างๆจะนำเสมอ ๏ ส่งทรัพยากรทางการศึกษา (i) นักศึกษาคลิกที่ไอคอนเพื่อแสดงทรัพยากรต่อไป (ii)ระบบเช็คว่าอะไรเป็นทรัพยากรในหลักสูตรที่นักศึกษาจะเรียนรู้ (iii)ส่งทรัพยากรที่ต้องการ(ระบุ)ให้นักศึกษา

25. ๏ดูทรัพยากร (i)ได้รับทรพยากรเพื่อที่จะแสดง (ii)เช็คชนิดตามความเหมาะสมตามชนิดของทรัพยากรนั้นๆ(text, video, slides) (iii)โหลดลงอุปกรณ์สร้างภาพ ๏ตอบคำถาม (i)รับคำตอบจากนักศึกษา (ii)เช็คชนิดของปัญหา (iii)เก็บคำตอบลงในประวัติของผู้ศึกษา ontology ตามชนิดของปัญหา

26. ๏เช็คคำตอบ (i)โหลดคำตอบในประวัติที่เก็บไว้ของนักศึกษา (ii)เช็คในthe pedagogical ontologyหาคำตอบของปัญหา (iii)เปรียบเทียบคำตอบของนักศึกษากับคำตอบที่ถูก (iv)เก็บผลไว้ในประวัติของนักศึกษา ๏เช็คความก้าวหน้าของหลักสูตร (i)รับทรัพยากรที่ได้จากนักศึกษา (ii)เช็คค่าของทรัพยากรในหลักสูตรของนักศึกษา (iii)อัพเดทลงในหลักสูตรของนักศึกษา

27. จากเรื่องของกรณีศึกษาเป็นจุดเริ่มต้นของการดำเนินการของ web service แบบเก่า ในกรณีศึกษา กรอบของApache Axis ที่ใช้สำหรับการพัฒนาของการอธิบายการบริการ และใช้ Tomcat 6.0 เป็น แอพพลิเคชันเซิร์ฟเวอร์ ดังนั้น ด้วยบริการที่มีการพัฒนา ข้อกำหนด(ontology)สำหรับรายละเอียดของบริการที่จะถูกสร้างขึ้น ความหมายของคำอธิบายของกรณีศึกษานี้จะถูกสร้างโดยใช้ OWL-S เพราะความเข้ากันของการดำเนินการของ Grinv กับ ตัวแปลภาษาของOWL-S

28. การป้อนข้อมูลและพารามิเตอร์ที่ส่งออกบริการของทรัพยากรที่เกี่ยวข้องกันกับข้อกำหนด(the ontologies)นั้นจะระบุโดเมนระบบ การป้อนข้อมูลพารามิตเตอร์มีความสัมพันธ์กับนักเรียนในห้องและพารามิเตอร์ออกมีความสัมพันธ์กับทรัพยากรในห้อง รูป 7 แสดงถึงส่วนของรายละเอียดที่สร้างขึ้นในตัวแปลภาษา OWL-S ในกระบวนการเดียวกันจะมีการทำซ้ำสำหรับการให้บริการอื่น ๆ ของระบบ

30. พัฒนาการของกลไกการร้องขอพัฒนาการของกลไกการร้องขอ อัลกอริทึมการร้องขอแบบอัติโนมัติจะสามารถปฏิบัติการ ร้องขอบริการ โดยการดำเนินการที่จำเป็นระหว่าง ข้อมูลเข้า และ ข้อมูลออก โดยไม่ต้องมีผู้ใช้มายุ่งเกี่ยวกับระบบ ผู้ใช้ต้องส่งข้อมูลเข้ามา และ กลไกการร้องขอ นี้จะต้องสามารถ ป้อนข้อมูลเข้ามาโดย ผู้ใช้ที่มีพารามิเตอร์บริการ พบโดย กลไกการค้นพบ

31. กลไกการร้องขอ ได้รับการพัฒนา โดยใช้ OWL-SAPI ที่มีความสามารถในการดำเนินการแบบไดนามิกที่มีกระบวนการดำเนินการแบบเรีบยง่าย การบูรณาเทคโนโลยี ขั้นตอนของการบูรณาการเทคโนโลยีสอดคลองกับการสร้างกลไกซึ่งจะช่วยให้กลไกการพัฒนาในขั้นตอนก่อนหน้าสามารถทำงานได้โดยอัตโนมัติโดยไม่ต้องมีการดำเนินการของผู้ใช้ คือ กลไกการบูรณาการนี้สามารถเชื่อถือได้สำหรับ การค้นพบ กระบวนการร้องขอ และผลที่ได้ เพื่อที่จะให้การดำเนินการชัดเจนสำหรับผู้ใช้

32. Grinv ดำเนินการผ่านกลไกการบรูณาการ ผู้จัดการต้องการความน่าเชื่อถือได้ของการดำเนินการบูรณาการของกระบวนการเพื่อรองรับการรองขอของผู้ใช้ แต่ มันเป็นสิ่งสำคัญเพื่อแสดงให้เห็นกลไกที่ได้รับการปรับแต่ง เพื่อให้ การกำหนดค่ามาตรฐาน สามารถสะม้อนให้เห็นทางเลือกในระบบของกลไกนี้ สำหรับกลไกนี้จะกำหนดค่าไฟล์ที่สร้าง ที่แสดงในรายการ 3 ที่มีข้อมูลเกี่ยวกับกลไกการพัฒนาในกรณีศึกษานี้

33. พัฒนาการการบริการ ในขั้นตอนนี้การดำเนินการของบริการที่สร้างขึ้น ในขั้นตอนที่เกิดขึ้นก่อนหน้าบทความที่กล่างถึงการพัฒนาการของบริการในรูป 6 ดังนั้น เรื่องของกรณีการใช้งานแต่ละบริการต่างๆจะนำเสมอ

34. Evaluation ในหมวดนี้แสดงการประเมินผลของกรณีศึกษาที่นำเสนอ ,แสดงให้เห็นปัญหาที่กล่าวถึงในส่วนที่ 2 คือ แก้ในการสร้าง ITS based บน Semantic Web Services ในกรณีนี้จะแสดงถึงสถาณการณ์จริงของการสร้าง ITS based บน Semantic Web Services ที่จะรับผิดชอบในส่วนของการอิมพลีเม้นคุณสมบัติของระบบ

35. ขั้นแรก จะกล่าวถึงคอนเซปหลักและโพรเซสของ ITS ตลอดจน use case และ ตารางคุณสมบัติ (Figs. 3 and 4). ใน Services Specification step Tutoring process จะถูกกำหนดจาก activity diagram (รูป. 5) เมื่อแต่ละ activity ที่เกี่ยวข้องกับ service หรือเซทของ service คุณสมบัติของแต่ละ activity แสดงในรูปแบบของพารามิเตอร์

36. สเตปถัดมาคือ Services Development ตรงส่วนที่ service ถูกอิมพลีเม้น ขั้นตอนที่ได้กล่าวไปในส่วนที่ 3 ตลอดโดนเมนเฉพาะและระบบบริการ sevice ได้อิมพลีเม้นและพัฒนา ประโยชน์สูงสุดของ Grinv เป็น Middleware คือ สามารถช่วยให้ง่ายต่อการ รวมกันระหว่างเทคโนโลยีที่ใช้ในกระบวนการค้นหา,ส่วนปรพกอบและการร้องขอของระบบเซอวิส

37. นอกจากนี้ ประโยชน์สูงสุดของ Grinv คือ การแก้ไขปัญหาที่มีเช่น การที่ไม่สามารถใช้ Static Planning ได้ ดังที่กล่าวในส่วนที่ 3.2.2 แต่สามารถให้ใช้ discovery process ผ่าน IOPE พารามิเตอร์ได้ จึงมั่นใจได้ว่าระบบมาสามารถใช้ Planing หรือ ใช้ IOPE สลับกันได้ หลีกเลี่ยงปัญหานี้ในระบบ ถ้า Grinv ใช้การกระจายปัญหาเพื่อหลีกเลี่ยงการ on loading Grinv อิมพลีเม้นกลไกสำหรับการอัพเดทอัตโนมัติไว้บนเว็บ เพื่อหลีกเลี่ยงการเกิดปัญหา

38. การรวมกันของกลไล : Grinv ให้ Requisition Manager, Discovery Controller และ Invocation Controller แก่ผู้พัฒนาสำหรับรวบรวมกระบวนการค้นพบและร้องขอ.ในส่วนนี้ Grinv จะอนุญาติให้ผู้ใช้เปลี่ยนเครื่องมือนี้โดยที่ไม่มีผลกระทบโดยตรงแก่ระบบอื่นๆ ดังที่แสดงในส่วนที่ 3.2.3,Grinv ได้อิมพลีเม้นเทคนิคสำหรับ fault tolerance ที่จะมั่นใจได้ว่าระบบจะได้หยุดทำงานในระหว่างที่กำลังใช้งาน

39. Development problems and current solutions การพัฒนาของปัญหาและวิธีการแก้ที่มีอยู่ ในส่วนนี้จะกล่าวถึงประเด็นที่เกี่ยวข้องกับสิ่งที่ประสบจากผู้พัฒนา process of building Semantic Web Services based systems. ในแต่ละปัญหา, พวกเราช่วยกันถกเถียงเกี่ยวกับการแก้ปัญหาที่เสนอมาโดยการอธิบายถึงประโยชน์และข้อจำกัด

40. วิจัยในการสร้าง Semantic Web Services based systems ที่บ่งชี้ถึง ปัญหาที่เกี่ยวข้องกับการบำรุงรักษาและการปฏิบัติของเครื่องมือและการบริการ ที่จะทำให้มันยากต่อการนำ application มาใช้ . ปัญหาเหล่านี้จะถูกกล่าวถึงด้านล่างนี้

41. 1.ไม่มีผู้ให้แนวทางในการพัฒนา: ผู้เขียนนำงานนี้มาใช้ใน Brambilla et al. (2007) โดยมี Model-Driven Design สำหรับการพัฒนา Semantic Web Services applications. พวกเขาใช้ WebML ในการกำหนดรูปแบบกระบวนการของระบบนี้ และกำหนดวิธีการสำหรับ generate Semantic Web Services ให้สอดคล้องกับรูปแบบกระบวนการ โดยการใช้ภาษา WSMO

42. อย่างไรก็ตาม, งานชิ้นนี้ไม่ใช่วิธีปัจจุบันสำหรับการพัฒนากลไกในการจัดการของการให้บริการ(การเก็บ,การค้นหา,องค์ประกอบ และ การร้องขอ). ในความเห็นของผู้เขียนงานชิ้นหนึ่งที่นำมาใช้ใน Weise et al. (2008) ใช้ความแตกต่างในการค้นพบและองค์ปรพกอบของอัลกอริทึ่ม. ดังนั้น,ตัวเลือกของกลไกควรจะพิจารณาในการพัฒนาของแต่ละ application ว่าตรงไหนคือส่วนที่ผิดพลาดของอัลกอริทึ่ม ที่นำไปสู่การพัฒนาที่ผิดๆ

43. 2.ใช้ Static Planningได้ไม่ทุกครั้ง : แม้จะมีการอนุญาตการให้บริการกับความซับซ้อนระดับสูง, การใช้ประโยชน์อย่างเต็มที่ผ่านStatic Planning ก็ไม่สามารถทำได้แก่ทุกระบบ. เช่นในกรณีของ METEOR-S (Aggarwal et al., 2004) project. ในระบบที่มีการเปลี่ยนแปลงสูง, process มีการเปลี่ยนแปลงแทบตลอดเวลา, ทำให้การใช้ Static Planning approach ไม่สามารถใช้ได้กำระบบลักษณะนี้. ปัญหานี้ก็เกิดในขึ้นในงานที่ Song et al. (2004), ซึ่งถูกเสนอเป็นการค้นพบทางไดนามิคในการให้บริการอย่างแพร่หลาย

44. 3.ความสามารถของการ loading ontologies : ภววิทยาสามารถใช้ได้บนเว็บ,นั่นหมายถึง, อย่างแรก applications จำเป็นต้องมี ontologies และกระบวนการของมันในการใช้หรือแต่ง Web Services. กระบวนการของ loading ontologies เกือบจะทั้งหมด เป็นการ bottleneck, เพราะผลกระทบเชิงลบ ของการทำงานของระบบ.ความเป็นไปได้ในการแก้ปัญหาสำหรับกรณีนี้คือการเก็บ ontologies ลงใน local database

45. วิธีนี้จะหลีกเลี่ยง ปัญหาการ loading ontology, อย่างที่วิธีนี้ประสบผลใน Broekstra et al. (2001). อย่างไรก็ตาม,การแก้ปัญหานี้ต้องการกลไกในการจัดการการเชื่อมต่อontologies ระหว่าง ontologies อันเดิมกับ ontologies ที่เก็บไว้ใน Lacal database.ซึ่งในกรณีนี้,ได้เพิ่มจุดผิดพลาดสำหรับระบบและเพิ่มการใช้ทรัพยากรระบบ, แม้จะสามารถเลี่ยงระบบในการทำงานแบบ out-of-date ontologies ได้

46. 4.การผสมผสานระหว่างกลไลการค้นพบและร้องขอ : กระบวนการของการบริการรับรองว่าได้ให้ระบบทำงานแบบไดนามิค,ตรงไหนที่ร้องขอและเข้าถึงที่ให้การบริการ ควรจะสามารถทำได้แบบอัตโนมัติโดยที่ไม่ต้องมีผู้ใช้หรือผู้พัฒนาติดต่อกันระหว่างระบบกับที่เก็บลิ้งนั้นๆ. ในกรณีนี้,ระบบควรเตรียมกลไกสำหรับการบูรณาการกระบวนการนี้. ในวิธีที่มีอยู่ เหมือนกับที่ใช้ทำ METEOR-S,กลไกนี้ไม่อนุญาตให้ผู้ใช้ปรับเปลี่ยนคุณสมบัติของระบบ, ซึ่งครั้งหนึ่งเคยทำ

47. 5.การ Fault tolerance : พื้นฐานของระบบบน SWS ต้องประสบกับการ error ในการ execute หรือ การจัดการกับ ontology จากปัญหาการเข้าถึงบนเนตเวิร์ค ปัญหานี้สามารถพบได้ใน Erl (2005) มันเกิดข้นเพราะ SWS เป็นพื้นฐานในการกระจายการให้บริการในหน้าเว็บ. ในทางเดียวกัน,ระบบนี้จำเป็นต้องเตรียมกลไกสำหรับ fault tolerance เพื่อหลีกเลี่ยงระบบจะหยุดขณะทำงาน และหากค้นพบการให้บริการที่ผิดพลาด,ระบบควรจะใช้กลไกการค้นหา เพื่อค้นการบริการที่คล้ายกันกับ faulty service โดยไม่ต้องให้ผู้ใช้มาลงมือหาเอง

48. ปัญหาอื่นที่เกี่ยวข้องกับ fault tolerance ที่เกี่ยวกับการให้บริการที่ผิด อาจะเป็น zombie, ส่วนที่เหลืออาจจะไม่ถูกใช้ในระบบอย่างไม่มีกำหนด, ก่อให้เกิดการต่อเนื่องและการไม่คาดหวัง ของ system error. ในกรณีนี้,ระบบไม่ควรอนุญาตให้ใช้ faulty service อย่างคุ้มค่าในกระบวนการของการค้นพบและร้องขอ จนถึงปัญหาระบบบที่ผิดผลาดอย่างคงที่.หมายถึงระบบไม่ควรละทิ้งการให้บริการอย่างถาวร