Transcript Engineering Applications of Artificial Intelligence

Engineering Applications of
Artificial Intelligence
1
เว็บเชิงความหมาย (Semantic Web)
คือส่ วนขยายของเว็บปัจจุบนั เพือ่ ทาให้การใช้ขอ้ มูลบนเว็บสามารถนามารี ยสู ได้ และเอื้อต่อ
เครื่ องจักรในการคิวรี อย่างเป็ นอัตโนมัติ ในปัจจุบนั
ข้อมูลที่ได้ถูกจัดทาขึ้นในเว็บเป็ นข้อมูลที่มีประโยชน์แต่ไม่เอื้อต่อเครื่ องจักรในการวิเคราะห์
หรื อคิวรี อย่างอัตโนมัติ เนื่องจากข้อมูลเหล่านั้นขาดโครงสร้างและเป็ นเพียงชิ้นส่วนของ
เท็กซ์ (Text) ซึ่งมนุษย์สามารถเข้าใจความหมาย แต่เครื่ องจักรไม่สามารถเข้าใจ
ความหมายได้
2
ในปี ค.ศ. 2001 นายทิม เบอร์เนอร์ ลี บิดาผูใ้ ห้กาเนิดเว็บได้นาเสนอหลักการเว็บเชิง
ความหมาย หรื อ Semantic Web (W3C, 2001) ซึ่งมีวตั ถุประสงค์ที่จะทาให้
ข้อมูลบนเว็บเป็ นข้อมูลที่มีประโยชน์ สามารถนาไปวิเคราะห์ รี ยสู (Reuse) เพื่อใช้งาน
ในแอพพลิเคชัน่ ต่าง ๆ และเอื้อต่อเครื่ องจักรสามารถสื บค้นได้อย่างอัตโนมัติ ตั้งแต่น้ นั เป็ น
ต้นมาเว็บเชิงความหมายได้เป็ นหัวข้อที่นกั วิจยั ได้ให้ความสนใจเป็ นอย่างมาก และถูกนาไป
ประยุกต์ใช้กบั หลาย ๆ เทคโนโลยี เช่น กริ ด (GRID) และ เว็บเซอร์วสิ (Web
services) โดยมีวตั ถุประสงค์ที่จะทาให้การทางานในเทคโนโลยีเหล่านั้นมี
ประสิ ทธิภาพมากขึ้น
3
โครงสร้างของเทคโนโลยีเว็บเชิงความหมายสามารถแสดงได้ดงั ภาพ
4
ซึ่งมีองค์ประกอบต่าง ๆ ได้แก่ มาตรฐานการอ้างอิงรี ซอร์ส ภาษาที่ใช้ในการอธิบายข้อมูล
เชิงความหมาย เช่น ภาษา XML และ XML Schema , RDF และ RDF
Schema
ภาษา Ontology เช่น ภาษา OWL ภาษา RDF เป็ นภาษาที่ใช้กาหนดโครงสร้าง
ของข้อมูลซึ่ งสามารถอธิบายความสัมพันธ์ขององค์ประกอบต่าง ๆ ที่บรรยายในเอกสารใน
รู ปแบบของประโยค (Statement) ซึ่งมีโครงสร้างประกอบด้วยซับเจกต์ (Subject)
รี เลชัน่ (relation) และ อ็อบเจกต์(object)
5
ภาษาออนโทโลจี (Ontology Lanuage) เป็ นภาษาที่ใช้ในการกาหนดคาศัพท์
(vocabulary) และคุณสมบัติ (Property) ต่าง ๆ สาหรับการอธิบายคอนเซ็ปต์
(Concept) ซึ่งคอนเซ็ปต์ คือสิ่ งต่าง ๆ ที่กาลังถูกบรรยายในโดเมนหนึ่ง ๆ
ออนโทโลจี (ontology) เป็ นข้อกาหนด (Specification) สาหรับอธิบายคอน
เซ็ปต์ในโดเมนหนึ่ง ๆ เพื่อให้ทุกคนในโดเมนนั้นสามารถเข้าใจในความหมายของสิ่ง
เหล่านั้นในทางเดียวกัน ซึ่ งข้อมูลที่อธิบายในออนโทโลจีแสดงข้อเท็จจริ ง (Fact) ของการ
ปรากฎของสิ่ งเหล่านั้นในโดเมน และอาจแสดงความรู ้ (Knowledge) ซึ่งได้จากการ
อนุมานออนโทโลจี (Ontology Reasoning) โดยใช้ขอ้ เท็จจริ งที่มีอยู่
6
ข้อมูลต่าง ๆ ที่บรรยายในเว็บเชิงความหมายอาจพิจารณาได้วา่ เป็ นภาษาเชิงโลจิกอย่างหนึ่ง
และการพิจารณาหาความหมายที่แท้จริ งของข้อมูลที่ได้บรรยายนั้น จาเป็ นทีจ่ ะต้องใช้กฎเป็ น
ส่ วนหนึ่งในการอนุมานออนโทโลจี (Ontology Reasoning) เพื่อค้นหาความรู้
ใหม่ (New Knowledge) ระดับชั้นโลจิกในสแตกของเว็บเชิงความหมายจึง
ครอบคลุมกฎ (Rule) และอาจรวมไปถึงภาษาเชิงโลจิกบางอย่างที่นามาใช้ในการอนุมาน
ออนโทโลจี กล่าวคือข้อมูลที่ถูกบรรยายโดยภาษาออนโทโลจี อาจถูกเปลี่ยนรู ปให้อยูใ่ น
ภาษาเชิงโลจิกภาษาใดภาษาหนึ่ง เพื่อใช้ในขบวนการอนุมานออนโทโลจี
7
พรู ฟ (Proof) เป็ นการพิสูจน์วา่ ข้อมูลเชิงความหมายที่ได้บรรยายในเว็บเชิงความหมาย
นั้น มีความน่าเชื่อถือได้หรื อไม่ ในการพิสูจน์อาจจะใช้กฎต่าง ๆ ในขบวนการพิสูจน์กไ็ ด้
ข้อมูลต่าง ๆ ในเว็บเชิงความหมาย ถือว่าเป็ นข้อมูลที่สามารถเผยแพร่ ได้อย่างเปิ ดเผยใน
ระบบเว็บ ซึ่งเอื้อต่อเครื่ องจักรในการคิวรี ดังนั้นในสแตกของเว็บเชิงความหมายจึงได้
กาหนดการรักษาความปลอดภัยของข้อมูลให้กบั ข้อมูลที่ถูกอธิบาย เช่น เอกสาร RDF
เอกสารออนโทโลจี หรื อส่ วนหนึ่งส่ วนใดของข้อมูลในเอกสารเหล่านั้นอาจมีการเข้ารหัส
เพื่อสร้างความปลอดภัยในการใช้งาน
8
9
Steps on development of systems based on Semantic Web
Services
ขั้นตอนในการพัฒนาตามแบบ semantci web service
แสดงให้เห็นถึงกระบวนการที่เกี่ยวข้องกับการพัฒนาของระบบตามแบบ SWS ขั้นตอน
ของกระบวนการนี้จะถูกนาเสนอดังนี้
10
1.Domain specification (ข้อกาหนดโดเมน)
โดเมนที่ระบุไว้อย่างเป็ นทางการผ่าน Ontology ซึ่ง Ontology เหล่านี้มี
วัตถุประสงค์เพื่อระบุแนวคิดและความสัมพันธ์กล่าวคือนักพัฒนาควรใช้วธิ ีการที่จะ
พัฒนาOntologyเหล่านี้ ซึ่ งได้นาเสนอวิธีการบางอย่างเพือ่ กาหนดวิธีการสาหรับสร้าง
Ontology ตามแบบ SWSคือไม่จาเป็ นต้องละเอียดถี่ถว้ นหรื อเฉพาะเจาะจง
11
2.Service specification (ข้อกาหนดการบริ การ)
จากข้อกาหนดในขั้นตอนก่อนหน้านี้ การบริ การมีหน้าที่รับผิดชอบในการ
ให้บริ การระบบฟังก์ชนั การทางานที่กาหนดไว้ ในขั้นตอนนี้กระบวนการของระบบถูกใช้ใน
การให้ขอ้ มูลที่จาเป็ นเพื่อดาเนินการค้นพบโดยใช้ การวางแผน
12
3.Services development (การพัฒนาการให้บริ การ)
ในขั้นตอนนี้ผบู้ ริ โภคสามารถค้นหาข้อมูลที่มีอยูแ่ ล้วสาหรับการให้บริ การ ซึ่ งก็
คือ สามรถลดเวลาการดาเนินงาน
ซึ่งมีสองแนวทางในการนาข้อมูลที่มีอยูแ่ ล้วมาใช้ ตามรู ปแบบของ SWS คือ
3.1 ข้อมูลการบริ การโดยไม่ได้อธิบายความหมาย: เนื่องจากไม่มีการอธิบายความหมาย
สาหรับการให้บริ การผูพ้ ฒั นาจะต้องสร้าง รายละเอียดของความหมายของข้อมูลการบริ การ
จับคู่บริ การ และนาไปหารู ปแบบ service ontology เอง
3.2 ข้อมูลการบริ การที่มีคาอธบายความหมายมาให้อยูแ่ ล้ว
13
4.Definitions of services repository (คาจากัดกัดของที่เก็บข้อมูลการ
บริ การ)
เนื่องจากระบบการบริ การได้ถูกอธิบายและพัฒนาไว้แล้ว ผูพ้ ฒั นาควรกาหนด
ชนิดของพื่นที่เก็บข้อมูลการให้บริ การด้วย
5.Development of discovery mechanisms (การพัฒนากลไกการ
ค้นพบ)
ผูพ้ ฒั นาได้อิมพลีเมนท์หรื อเลือกกลไกสาหรับ service discovery และ
automatic service composition
กลไกการสื บค้น
14
มีหน้าที่ต่อการจัดการบริ การเพื่อตรวจสอบซึ่ ง service จะทาการทางานแบบไดนามิค
ตลอดที่ผใู้ ช้ยงั ใช้งานอยู่
มันสาคัญต่อการบ่งชี้วา่ เซอร์วสิ ที่ถูกเลือกการกลไกการค้นพบไม่จาเป็ นต้อง
ได้รับการพัฒนาใน Services Development step.
เมื่อ intelligent systems พัฒนาอย่างต่อเนื่องการบริ การใหม่ๆได้ถูกเพิ่ม
เข้ามา และทางเลือกสาหรับการบริ การนี้จะสามารถเพิ่มประสิ ทธิภาพให้แก่ระบบได้
ตัวอย่างอื่นเช่นเพิ่มลงที่เก็บข้อมูล เพื่อลดความซ้ าซ้อน.ในกรณี ของการ error
ระหว่าง execute ใน service ทัว่ ไป , กลไกการค้นพบต้องค้นหาการ
ให้บริ การที่เหมือนกันเจอโดยอัตโนมัติ โดยที่ไม่ตอ้ งติดต่อผูพ้ ฒั นาโดยตรง
15
6.Development of invocation mechanisms (การพัฒนากลไกการร้อง
ขอ)
กลไกการร้องขอต้องถูกพัฒนาเพื่อเรี ยกร้องบริ การที่เลือก โดยกลไกที่คน้ พบนี้
จะต้องยืนยันได้วา่ ผูใ้ ช้สามารถใช้งานได้จริ ง
7.Technologies integration (การรวบรวมเทคโนโลยี)
ขั้นตอนนี้จะเป็ นผูร้ ับผิดชอบสาหรับรวบรวมเครื่ องมือที่ใช้ในการจัดการบริ การ
ที่จาเป็ น
16
GRINV เป็ นซอฟท์แวร์ที่ทาหน้าที่เป็ นสื่ อกลางระหว่างผูใ้ ช้กบั แอปพลิเคชัน่ หรื อ
ระหว่างโปรแกรมต่างๆ
เป็ น Middleware ที่มีจุดมุ่งหมายคือ การค้นพบ การร้องขออัตโนมัติต่อ
Semantic Web Service
Grinv ยังให้พ้นื ที่เก็บข้อมูลของบริ การที่มีวตั ถุประสงค์เพื่อ ลดปัญหา
ประสิ ทธิภาพการทางานที่พบในการโหลดของ Ontology
นอกจากนี้ Grinv ยังสามารถรวบรวมเทคโนโลยีของพื้นที่การให้บริ การ
17
18
19
20
21
22
provider
requester
registry
provider
registry
registry
23
พัฒนาการการบริ การ
ในขั้นตอนนี้การดาเนินการของบริ การที่สร้างขึ้น ในขั้นตอนที่เกิดขึ้นก่อนหน้าบทความที่
กล่างถึงการพัฒนาการของบริ การในรู ป 6 ดังนั้น เรื่ องของกรณี การใช้งานแต่ละบริ การต่างๆ
จะนาเสมอ
๏ ส่ งทรัพยากรทางการศึกษา
(i) นักศึกษาคลิกที่ไอคอนเพื่อแสดงทรัพยากรต่อไป
(ii)ระบบเช็คว่าอะไรเป็ นทรัพยากรในหลักสูตรที่นกั ศึกษาจะเรี ยนรู้
(iii)ส่ งทรัพยากรที่ตอ้ งการ(ระบุ)ให้นกั ศึกษา
24
๏ดูทรัพยากร
(i)ได้รับทรพยากรเพื่อที่จะแสดง
(ii)เช็คชนิดตามความเหมาะสมตามชนิดของทรัพยากรนั้นๆ(text, video, slides)
(iii)โหลดลงอุปกรณ์สร้างภาพ
๏ตอบคาถาม
(i)รับคาตอบจากนักศึกษา
(ii)เช็คชนิดของปัญหา
(iii)เก็บคาตอบลงในประวัติของผูศ้ ึกษา ontology ตามชนิดของปัญหา
25
๏เช็คคาตอบ
(i)โหลดคาตอบในประวัติที่เก็บไว้ของนักศึกษา
(ii)เช็คในthe pedagogical ontologyหาคาตอบของปัญหา
(iii)เปรี ยบเทียบคาตอบของนักศึกษากับคาตอบที่ถูก
(iv)เก็บผลไว้ในประวัติของนักศึกษา
๏เช็คความก้าวหน้าของหลักสูตร
(i)รับทรัพยากรที่ได้จากนักศึกษา
(ii)เช็คค่าของทรัพยากรในหลักสูตรของนักศึกษา
(iii)อัพเดทลงในหลักสูตรของนักศึกษา
26
จากเรื่ องของกรณี ศึกษาเป็ นจุดเริ่ มต้นของการดาเนินการของ web service แบบเก่า ใน
กรณี ศึกษา
กรอบของApache Axis ที่ใช้สาหรับการพัฒนาของการอธิบายการบริ การ และใช้
Tomcat 6.0 เป็ น แอพพลิเคชันเซิร์ฟเวอร์ ดังนั้น ด้วยบริ การที่มีการพัฒนา ข้อกาหนด
(ontology)สาหรับรายละเอียดของบริ การที่จะถูกสร้างขึ้น
ความหมายของคาอธิบายของกรณี ศึกษานี้จะถูกสร้างโดยใช้ OWL-S เพราะความเข้า
กันของการดาเนินการของ Grinv กับ ตัวแปลภาษาของOWL-S
27
การป้ อนข้อมูลและพารามิเตอร์ที่ส่งออกบริ การของทรัพยากรที่เกี่ยวข้องกันกับข้อกาหนด
(the ontologies)นั้นจะระบุโดเมนระบบ การป้ อนข้อมูลพารามิตเตอร์มีความสัมพันธ์
กับนักเรี ยนในห้องและพารามิเตอร์ออกมีความสัมพันธ์กบั ทรัพยากรในห้อง รูป 7 แสดงถึง
ส่ วนของรายละเอียดที่สร้างขึ้นในตัวแปลภาษา OWL-S ในกระบวนการเดียวกันจะมี
การทาซ้ าสาหรับการให้บริ การอื่น ๆ ของระบบ
28
29
พัฒนาการของกลไกการร้องขอ
อัลกอริ ทึมการร้องขอแบบอัติโนมัติจะสามารถปฏิบตั ิการ ร้องขอบริ การ โดยการดาเนินการ
ที่จาเป็ นระหว่าง
ข้อมูลเข้า และ ข้อมูลออก โดยไม่ตอ้ งมีผใู ้ ช้มายุง่ เกี่ยวกับระบบ ผูใ้ ช้ตอ้ งส่ งข้อมูลเข้ามา และ
กลไกการร้องขอ
นี้จะต้องสามารถ ป้ อนข้อมูลเข้ามาโดย ผูใ้ ช้ที่มีพารามิเตอร์บริ การ พบโดย กลไกการค้นพบ
30
กลไกการร้องขอ ได้รับการพัฒนา โดยใช้ OWL-SAPI ที่มีความสามารถในการ
ดาเนินการแบบไดนามิกที่มีกระบวนการดาเนินการแบบเรี บยง่าย
การบูรณาเทคโนโลยี
ขั้นตอนของการบูรณาการเทคโนโลยีสอดคลองกับการสร้างกลไกซึ่ งจะช่วยให้กลไกการ
พัฒนาในขั้นตอนก่อนหน้าสามารถทางานได้โดยอัตโนมัติโดยไม่ตอ้ งมีการดาเนินการของ
ผูใ้ ช้ คือ กลไกการบูรณาการนี้สามารถเชื่อถือได้สาหรับ การค้นพบ กระบวนการร้องขอ
และผลที่ได้ เพื่อที่จะให้การดาเนินการชัดเจนสาหรับผูใ้ ช้
31
Grinv ดาเนินการผ่านกลไกการบรู ณาการ ผูจ้ ดั การต้องการความน่าเชื่อถือได้ของการ
ดาเนินการบูรณาการของกระบวนการเพื่อรองรับการรองขอของผูใ้ ช้ แต่ มันเป็ นสิ่ งสาคัญ
เพื่อแสดงให้เห็นกลไกที่ได้รับการปรับแต่ง เพื่อให้
การกาหนดค่ามาตรฐาน สามารถสะม้อนให้เห็นทางเลือกในระบบของกลไกนี้ สาหรับกลไก
นี้จะกาหนดค่าไฟล์ที่สร้าง ที่แสดงในรายการ 3 ที่มีขอ้ มูลเกี่ยวกับกลไกการพัฒนาใน
กรณี ศึกษานี้
32
พัฒนาการการบริ การ
ในขั้นตอนนี้การดาเนินการของบริ การที่สร้างขึ้น ในขั้นตอนที่เกิดขึ้นก่อนหน้าบทความที่
กล่างถึงการพัฒนาการของบริ การในรู ป 6 ดังนั้น เรื่ องของกรณี การใช้งานแต่ละบริ การต่างๆ
จะนาเสมอ
33
Evaluation
ในหมวดนี้แสดงการประเมินผลของกรณี ศึกษาที่นาเสนอ
,แสดงให้เห็นปั ญหาที่กล่าวถึงในส่ วนที่ 2 คือ
แก้ในการสร้าง ITS based บน Semantic Web Services
ในกรณี น้ ีจะแสดงถึงสถาณการณ์จริ งของการสร้าง ITS based บน Semantic
Web Services ที่จะรับผิดชอบในส่ วนของการอิมพลีเม้นคุณสมบัติของระบบ
34
ขั้นแรก
จะกล่าวถึงคอนเซปหลักและโพรเซสของ ITS ตลอดจน use case และ ตาราง
คุณสมบัติ (Figs. 3 and 4).
ใน Services Specification step Tutoring process จะถูกกาหนดจาก
activity diagram (รู ป. 5) เมื่อแต่ละ activity ที่เกี่ยวข้องกับ service หรื อเซท
ของ service
คุณสมบัติของแต่ละ activity แสดงในรู ปแบบของพารามิเตอร์
35
สเตปถัดมาคือ Services Development ตรงส่ วนที่ service ถูกอิมพลีเม้น
ขั้นตอนที่ได้กล่าวไปในส่ วนที่ 3 ตลอดโดนเมนเฉพาะและระบบบริ การ
sevice ได้อิมพลีเม้นและพัฒนา
ประโยชน์สูงสุ ดของ Grinv เป็ น Middleware คือ สามารถช่วยให้ง่ายต่อการ
รวมกันระหว่างเทคโนโลยีที่ใช้ในกระบวนการค้นหา,ส่ วนปรพกอบและการร้องขอของ
ระบบเซอวิส
36
นอกจากนี้ ประโยชน์สูงสุ ดของ Grinv คือ การแก้ไขปัญหาที่มีเช่น
การที่ไม่สามารถใช้ Static Planning ได้
ดังที่กล่าวในส่ วนที่ 3.2.2 แต่สามารถให้ใช้ discovery process ผ่าน IOPE
พารามิเตอร์ได้
จึงมัน่ ใจได้วา่ ระบบมาสามารถใช้ Planing หรื อ ใช้ IOPE สลับกันได้
หลีกเลี่ยงปัญหานี้ในระบบ
ถ้า Grinv ใช้การกระจายปัญหาเพื่อหลีกเลี่ยงการ on loading
Grinv อิมพลีเม้นกลไกสาหรับการอัพเดทอัตโนมัติไว้บนเว็บ
เพื่อหลีกเลี่ยงการเกิดปัญหา
37
การรวมกันของกลไล : Grinv ให้ Requisition Manager, Discovery
Controller และ Invocation Controller
แก่ผพู้ ฒั นาสาหรับรวบรวมกระบวนการค้นพบและร้องขอ.ในส่ วนนี้ Grinv จะอนุญาติ
ให้ผใู้ ช้เปลี่ยนเครื่ องมือนี้โดยที่ไม่มีผลกระทบโดยตรงแก่ระบบอื่นๆ
ดังที่แสดงในส่ วนที่ 3.2.3,Grinv ได้อิมพลีเม้นเทคนิคสาหรับ
fault tolerance ที่จะมัน่ ใจได้วา่ ระบบจะได้หยุดทางานในระหว่างที่กาลังใช้งาน
38
Development problems and current solutions
การพัฒนาของปัญหาและวิธีการแก้ที่มีอยู่
ในส่ วนนี้จะกล่าวถึงประเด็นที่เกี่ยวข้องกับสิ่ งที่ประสบจากผูพ้ ฒั นา process of
building Semantic Web Services based systems.
ในแต่ละปัญหา, พวกเราช่วยกันถกเถียงเกี่ยวกับการแก้ปัญหาที่เสนอมาโดยการอธิบายถึง
ประโยชน์และข้อจากัด
39
วิจยั ในการสร้าง Semantic Web Services based systems ที่บ่งชี้ถึง
ปัญหาที่เกี่ยวข้องกับการบารุ งรักษาและการปฏิบตั ิของเครื่ องมือและการบริ การ
ที่จะทาให้มนั ยากต่อการนา application มาใช้ .
ปัญหาเหล่านี้จะถูกกล่าวถึงด้านล่างนี้
40
1.ไม่มีผใู้ ห้แนวทางในการพัฒนา: ผูเ้ ขียนนางานนี้มาใช้ใน Brambilla et al.
(2007) โดยมี
Model-Driven Design สาหรับการพัฒนา Semantic Web Services
applications.
พวกเขาใช้ WebML ในการกาหนดรู ปแบบกระบวนการของระบบนี้
และกาหนดวิธีการสาหรับ generate Semantic Web Services ให้สอดคล้อง
กับรู ปแบบกระบวนการ
โดยการใช้ภาษา WSMO
41
อย่างไรก็ตาม, งานชิ้นนี้ไม่ใช่วธิ ีปัจจุบนั สาหรับการพัฒนากลไกในการจัดการของการ
ให้บริ การ(การเก็บ,การค้นหา,องค์ประกอบ และ การร้องขอ).
ในความเห็นของผูเ้ ขียนงานชิ้นหนึ่งที่นามาใช้ใน Weise et al. (2008) ใช้ความ
แตกต่างในการค้นพบและองค์ปรพกอบของอัลกอริ ท่ ึม.
ดังนั้น,ตัวเลือกของกลไกควรจะพิจารณาในการพัฒนาของแต่ละ application ว่า
ตรงไหนคือส่ วนที่ผดิ พลาดของอัลกอริ ท่ ึม ที่นาไปสู่การพัฒนาที่ผดิ ๆ
42
2.ใช้ Static Planningได้ไม่ทุกครั้ง : แม้จะมีการอนุญาตการให้บริ การกับความ
ซับซ้อนระดับสูง,
การใช้ประโยชน์อย่างเต็มที่ผา่ นStatic Planning ก็ไม่สามารถทาได้แก่ทุกระบบ.
เช่นในกรณี ของ METEOR-S (Aggarwal et al., 2004) project.
ในระบบที่มีการเปลี่ยนแปลงสูง, process มีการเปลี่ยนแปลงแทบตลอดเวลา, ทาให้การ
ใช้ Static
Planning approach ไม่สามารถใช้ได้การะบบลักษณะนี้.
ปัญหานี้กเ็ กิดในขึ้นในงานที่ Song et al. (2004), ซึ่งถูกเสนอเป็ นการค้นพบทางได
นามิคในการให้บริ การอย่างแพร่ หลาย
43
3.ความสามารถของการ loading ontologies : ภววิทยาสามารถใช้ได้บนเว็บ,นัน่
หมายถึง,
อย่างแรก applications จาเป็ นต้องมี ontologies และกระบวนการของมันในการ
ใช้หรื อแต่ง Web Services.
กระบวนการของ loading ontologies เกือบจะทั้งหมด เป็ นการ bottleneck,
เพราะผลกระทบเชิงลบ
ของการทางานของระบบ.ความเป็ นไปได้ในการแก้ปัญหาสาหรับกรณี น้ ีคือการเก็บ
ontologies ลงใน local database
44
วิธีน้ ีจะหลีกเลี่ยง ปัญหาการ loading ontology, อย่างที่วธิ ีน้ ีประสบผลใน
Broekstra et al. (2001).
อย่างไรก็ตาม,การแก้ปัญหานี้ตอ้ งการกลไกในการจัดการการเชื่อมต่อontologies
ระหว่าง ontologies อันเดิมกับ
ontologies ที่เก็บไว้ใน Lacal database.ซึ่ งในกรณี น้ ี,ได้เพิม่ จุดผิดพลาดสาหรับ
ระบบและเพิม่ การใช้ทรัพยากรระบบ,
แม้จะสามารถเลี่ยงระบบในการทางานแบบ out-of-date ontologies ได้
45
4.การผสมผสานระหว่างกลไลการค้นพบและร้องขอ :
กระบวนการของการบริ การรับรองว่าได้ให้ระบบทางานแบบไดนามิค,ตรงไหนที่ร้องขอ
และเข้าถึงที่ให้การบริ การ
ควรจะสามารถทาได้แบบอัตโนมัติโดยที่ไม่ตอ้ งมีผใู ้ ช้หรื อผูพ้ ฒั นาติดต่อกันระหว่างระบบ
กับที่เก็บลิ้งนั้นๆ.
ในกรณี น้ ี,ระบบควรเตรี ยมกลไกสาหรับการบูรณาการกระบวนการนี้.
ในวิธีที่มีอยู่ เหมือนกับที่ใช้ทา METEOR-S,กลไกนี้ไม่อนุญาตให้ผใู้ ช้ปรับเปลี่ยน
คุณสมบัติของระบบ,
ซึ่งครั้งหนึ่งเคยทา
46
5.การ Fault tolerance : พื้นฐานของระบบบน SWS ต้องประสบกับการ error
ในการ execute หรื อ การจัดการกับ
ontology จากปัญหาการเข้าถึงบนเนตเวิร์ค
ปัญหานี้สามารถพบได้ใน Erl (2005) มันเกิดข้นเพราะ SWS เป็ นพื้นฐานในการ
กระจายการให้บริ การในหน้าเว็บ.
ในทางเดียวกัน,ระบบนี้จาเป็ นต้องเตรี ยมกลไกสาหรับ fault tolerance เพื่อหลีกเลี่ยง
ระบบจะหยุดขณะทางาน
และหากค้นพบการให้บริ การที่ผดิ พลาด,ระบบควรจะใช้กลไกการค้นหา เพื่อค้นการบริ การ
ที่คล้ายกันกับ faulty service
โดยไม่ตอ้ งให้ผใู้ ช้มาลงมือหาเอง
47
ปัญหาอื่นที่เกี่ยวข้องกับ fault tolerance ที่เกี่ยวกับการให้บริ การที่ผดิ
อาจะเป็ น zombie, ส่ วนที่เหลืออาจจะไม่ถูกใช้ในระบบอย่างไม่มีกาหนด,
ก่อให้เกิดการต่อเนื่องและการไม่คาดหวัง ของ system error.
ในกรณี น้ ี,ระบบไม่ควรอนุญาตให้ใช้ faulty service อย่างคุม้ ค่าในกระบวนการของ
การค้นพบและร้องขอ
จนถึงปัญหาระบบบที่ผดิ ผลาดอย่างคงที่.หมายถึงระบบไม่ควรละทิ้งการให้บริ การอย่าง
ถาวร
48