DAĞITIK ETMEN SĠSTEMLERĠNDE BAĞLI VERĠ YÖNETĠMĠ Ege Üniversitesi Fen Bilimleri Enstitüsü Bilgisayar Mühendisliği Anabilim Dalı Ziya Akar 28.03.2011
İçerik Günümüzde Web Bağlı Veri Kavramı Avantajları Prensipleri Ortaya çıkması sonucu gerektirdikleri Gerçekleştirimi Etmenlerin Bağlı Veri Kullanarak Web'e Açılması Etmenlerde Bağlı Verilerin Depolanması 2
İçerik Etmenlerin Bağlı Veri İçeriklerini Sorgulamaları Etmenlerin, etmenlerin verisetlerini sorgulamaları Etmenlerin, web üzerindeki verisetlerini sorgulamaları Etmenlerin, birden fazla verisetini sorgulamaları Etmenlerin Bağlı Veri Setlerini Araması Etmenlerin Bağlı Verileri Görüntülemesi Tamamlananlar Tamamlanacaklar Referanslar 3
Günümüzde Web Web üzerinde yaklaşık 13.2 milyar sayfa bulunmaktadır. Bu büyüklüğe paralel olarak istenilen veriye erişim sorunu ortaya çıkmaktadır. Anlamsal Web, klasik web'in bu veriye erişim sorununu hem kullanıcılar hem de yazılımlar için web içeriklerini ontoloji dilleri ile temsil ederek çözmektedir ve kullanımı yaygınlaşmaktadır. Bu sayede web içerikleri belirli bir standartta yaratılmakta ve verilerin keşfi kolay bir hale gelmektedir. 4
Bağlı Veri Kavramı Bağlı veri, anlamsal web'in içeriğini oluşturan yapısal verinin bağlanması ve yayınlanması için en uygun yaklaşımlardan biridir. Daha teknik bir tanımla, verilerin nerede tutulduklarından bağımsız olarak, W3C'nin üstveri veri modeli olarak belirttiği RDF(Resource Description Framework) denilen bir modelleme yaklaşımıyla tanımlandığı veriler topluluğudur[7] diye tanımlanabilir. 5
Bağlı Verinin Avantajları Farklı uygulama alanlarındaki(insanlar, şirketler, kitaplar, filmler, müzikler, vb...) verilerin birbirine bağlanması ile web'in genişlemesine katkıda bulunur[3]. Çoklu, dağıtık ve heterojen kaynaklardan getirilen verilerin tümleşimi sağlanır[3]. Verilerin birbirine bağlanarak büyük bir ağ oluşturmasıyla aramalara ve sorgulamalara daha etkin cevaplar verilmesi sağlanır[3]. Ontoloji dilleri ile gerçekleştirilmeleri sayesinde sadece insanlar değil yazılımlar da bu avantajlardan faydalanabilirler. 6
Bağlı Veri Prensipleri Tüm bu avantajları sunan bağlı verilerin, yaratılırken ve yayımlanırken uyulması gereken bazı prensipler Tim Berners-Lee tarafından şu şekilde belirtilmiştir[1]: Web üzerinde tanımlanacak herşey için URI(Uniform Resource Identifier) kullanılmalı. İnsanların bu URI'leri arayabilmeleri için http URI'leri kullanılmalı. Bir URI arandığında yani tanımlanan kaynak ile ilgili bilgilere erişilmek istendiğinde bazı standartlar(rdf, SPARQL) kullanarak kullanışlı bilgiler sunulmalıdır. Kaynakları temsil eden URI'ler ile diğer kaynak URI'leri arasında RDF bağları tanımlanmalıdır. 7
Bağlı Verinin Gerektirdikleri Bağlı veri prensiplerine uyularak veriler sadece yaratılmış ve yayınlanmış olurlar. Ancak etkin kullanım için bazı gereksinimlere ihtiyaç vardır. Çünkü var olan web mimarisi bunun için yeterli değildir. Var olan web mimarisindeki, Tarayıcılar sadece HTML bağları ile birbirine bağlı web sayfaları arasında gezinebilmektedir. Arama motorları metin tabanlı aramalar yapmaktadır. Web sayfaları arasındaki bağlar anlamsal olmadıkları için bir veri ile ilişkili veri toplulukları bir arada değildir, dağınık bir haldedir, anlamlı bir bütünlük yoktur. 8
Bağlı Verinin Gerektirdikleri Bağlı verilerin etkin kullanımı için mimaride, Tarayıcıların bağlı olan veriler arasında gezinebilmesi ve verilerle ilişkili bilgileri göstermeleri gerekmektedir. Arama motorları ile verilerin yer aldıkları veri setleri ve veri ile ilişkili veriler bulunabilmelidir. Sorgulama mekanizmaları ile çok daha büyük ölçekli bütünleşik veri toplulukları bir araya getirilerek üzerinde anlamsal veriler sorgulanabilmelidir. 9
Bağlı Verinin Gerektirdikleri Bu gereksinimlerin sonuçları olarak bağlı veri mimarisine uygun bazı araçlar gerçekleştirilmiştir: Sig.ma, Tabulator[15], ODE(OpenLink Data Explorer) gibi bağlı veri tarayıcıları Sindice[14], swoogle gibi bağlı veri arama motorları DARQ[13], SQUIN[12] gibi sorgulama motorları CKAN[11](Comprehensive Knowledge Archive Network) gibi verisetlerinin uç noktalarının kayıtlı olduğu ağlar. Görüldüğü gibi anlamsal web içeriğini oluşturan bağlı verilerden dolayı bağlı veri mimarisi klasik web mimarisinden farklı özellikler taşımakta ve başlıca, veriler arasında gezinebilen, anlamsal aramalar yapabilen ve sorgulamalar yapabilen mekanizmalar gerektirmektedir. 10
Bağlı Veri Gerçekleştirimi Klasik web'deki web sayfaları içerisindeki bilgilerin ne ile ilgili oldukları ve ne hakkında olduklarının açıkça belirtilmesi, aralarında anlamsal ilişkiler kurulması ve klasik web'deki karmaşık yapıdan kurtulabilmek için Tim Berners-Lee'nin belirlediği bağlı veri prensiplerine[1] de bağlı kalarak anlamsal veriler yaratılmalıdır. Bu gerçekleştirilirken, web üzerinde veri değişimi için standart bir model olan RDF[5] teknolojisinden yararlanılır. RDF ile web üzerinde kaynak tanımlamaları yapılırken URI'lerden faydalanılır ki bu da bağlı veri prensiplerindeki kaynak tanımlamaları ile örtüşmektedir. 11
Bağlı Veri Gerçekleştirimi İyi bir URI şunları sağlamalıdır[6]: Bir URI, HTTP protokolü ile web üzerinden insanlar içi HTML dökümanları, yazılımlar için ise RDF verisi getirebiliyor olmalıdır. URI'ler kısa, akılda kalıcı ve basit olmalıdır. Uzun süre değişmeyecek şekilde düşünülmelidir, teknoljik terimler(.rdf,.xml, vb... uzantılar) içermemelidir. Bir URI sadece tek bir kaynağı temsil etmelidir. Kaynak tanımlamaları için bilinen 2 tip URI tanımlama çözümü vardır. 303 URI çözümü Hash URI çözümü 12
Bağlı Veri Gerçekleştirimi 303 URI çözümü Kaynakları, klasik web dökümanlarından ayırmak için kullanılır. Eğer HTML dökümanına erişim isteniyorsa HTML dökümanı URI'sine, RDF dökümanına erişim için RDF döküman URI'sine yönlendirilir. RDF dökümanında sadece kaynakla ilgili tanımlalamalar yer almaktadır. 303 URI'leri kaynağa özgüdür. Bu yüzden boyutları küçüktür. Ancak çok fazla yönlendirme ve istek bildirimi olduğundan dökümanlara erişirken gecikmeler yaşanabilir. 13
Bağlı Veri Gerçekleştirimi 303 URI çözümü 14
Bağlı Veri Gerçekleştirimi - Hash URI çözümü Hash URI yaklaşımında ise RDF dökümanı birden fazla kaynak tanımını içerir. Buradaki URI yapısının bir kısmı RDF dökümanında yer alan tüm kaynakların bulunduğu RDF dökümanının URI'sidir. # gibi özel bir işaretten sonra gelen kısım ise kaynağı belirleyici olan kısımdır. Bu yaklaşımdaki RDF dökümanlarının boyutları 303 URI yaklaşımına nazaran büyüktür. Ancak gecikmeler yaşanmaz. Şema dökümanları gibi bir arada olması gereken kaynaklar için uygundur. 15
Bağlı Veri Gerçekleştirimi - Hash URI çözümü 16
Etmenlerin Web'e Açılması Bilgiye kolay erişimin sağlandığı anlamsal web ortamından etmenlerin de yararlanabilmesi için etmenlerin bilgi tabanları ve bilgiye erişim yöntemleri anlamsal web teknolojileri ile gerçekleştirilmeli, anlamsal web ile uyumlu olmaları gerekmektedir. Etmenler günümüzde klasik web üzerinde de var olan verileri nerede arayacaklarını bilememeleri sorunu, bilgi tabanı alt yapılarının birbirleri ile ve anlamsal web ile tam uyumlu olmaması nedeni ile henüz tam bir tümleşim ve uyumdan söz edilememektedir. 17
Etmenlerin Web'e Açılması Etmenlerin web'e açılabilmesi ve anlamsal web ortamına uyum sağlayabilmesi için, Kendi verilerini tanımlarken bağlı veri prensiplerine uymalıdırlar. Etmenler altyapılarında anlamsal web'de de olduğu gibi bağlı veriler arasında gezinebilme ve görüntüleyebilme, arama ve sorgulama mekanizmalarını gerçekleştirmelidir. Bu gereksinimler, özellikle çoklu etmen sistemlerindeki etmenlerin, birbirleriyle sürekli iletişim halinde olmaları ve geniş bir coğrafyada dağıtık halde bulunmalarından dolayı birbirlerinin hangi konumda olduklarını biliyor olmaları ve veri alışverişi yapmaya ihtiyaç duymaları nedeniyle gerçekleştirilmelidir. 18
Etmenlerin Web'e Açılması - Etmen kaynaklarının URI tanımlamaları Etmenler kaynak tanımlamaları için bir URI çözümünü seçmelidirler. SEAGENT etmenlerinin kaynak tanımlamaları için daha önce bahsedilen URI çözümlemelerinden Hash URI çözümü seçildi ve şu şekilde bir yapılandırmaya gidildi: 19
Etmenlerin Web'e Açılması - Etmen kaynaklarının URI tanımlamaları Bu URI yapısı sayesinde URI'nin içerisinde bulunan etmen_ismi kısmı ile kaynak tanımlamasının hangi etmenin bilgi tabanında olduğu temsil edilmektedir. cizge_ismi denilen kısım ile de verinin hangi RDF dökümanında olduğu temsil edilmektedir. Etmenlerin URI seçiminde daha önce bahsedilen URI çözümlerinin avantajlarını ve dezavantajlarını göz önüne almaları gerekmektedir. SEAGENT için seçilen bu URI çözümünün gerekçeleri şunlardır: Büyük veri toplulukları üzerinde çıkarsama yapılmak istenebilir. Ortak bir alana ait veri toplulukları bir arada tutulmak istenmiştir. Çünkü ayrık tutulduğunda arama veya sorgulama için tekrar bir araya getirmek için efor sarf etmek gerekecektir. Ancak büyük verisetlerini sorgulamak için gerekecek zaman hala bir eksikliktir. 20
Etmenlerin Web'e Açılması - Etmen kaynaklarının web üzerinde sunulması Etmenler bağlı veri prensiplerine uygun bir şekilde yaratıldıktan sonra sadece birbirleri arasında alınıp verilebilirler. Farklı yazılımlarla ve diğer etmenlerle paylaşmak istedikleri verilerini web üzerinde de sunmaları gerekmektedir. Etmen kaynakların web üzerinde erişilebilir olması için, Paylaşılmak istenen kaynaklar tıpkı anlamsal web'deki gibi bir sunucuda tutulması, istek durumunda HTML ya da RDF dökümanı ile kaynak tanımlarının erişilebilir olması sağlanabilir. Ya da bir SPARQL endpoint ile sorgulanmak üzere dışarıya açılabilirler. Bu uç noktalar SPARQL sorguları ile verisetlerinin sorgulanmasını sağlarlar. SEAGENT etmenlerinin kaynakları web tabanlı bir SPARQL uçnoktası olan[8] JOSEKI ile dışarıya sunulmaya çalışılmaktadır. 21
Etmenlerde Bağlı Verilerin Depolanması Etmenlere ait bağlı veriler subject, predicate, object denilen ve <s,p,o> şeklinde gösterilen üçlü ler şeklinde temsil edilmektedir. Subject: Tanımlanan kaynak URI'sini temsil eder. Object : Bir başka kaynak URI'si veya bir RDF literalini temsil eder. Predicate : Subject ile object arasındaki ilişkiyi temsil eden bir URI ile tanımlanan kaynaktır. Üçlüler yani RDF verileri, triple store denilen veritabanlarında kayıtlı tutulmalıdırlar. Çünkü bu özel veritabanları, ilişkisel veritabanlarının aksine anlamsal veri setlerini sorgulayabilen SPARQL denilen sorgulama dili ile sorgulanabilir. 22
Etmenlerde Bağlı Verilerin Depolanması Bunun için var olan teknolojilerden başlıcaları: AllegroGraph, Jena SDB[16], Mulgara, Sesame, Soprano, Virtuoso vb... SEAGENT etmenlerinin kaynaklarının depolanması için Jena SDB triple store seçilmiştir. Kaynak tanımlamalarının bulunduğu RDF modellerinin yaratımı için kullanılan Jena Framework'ü aynı zamanda yaratılan kaynakların depolanması için de kullanılmıştır. Yaratılan her kaynak tanımlaması bir RDF modeli içerisinde yer almaktadır. Her RDF modeli triple store'da yer alan bir çizge(graph)'ye denk gelmektedir. Çizge adresleri SEAGENT kaynak URI'leri içerisinde yer almaktadır. 23
Etmenlerde Bağlı Verilerin Depolanması 24
Etmenlerin Bağlı Veri İçeriklerini Sorgulamaları Etmenler kendi verilerini hem kendi bilgi tabanları üzerinde hem de web üzerinde yayınlayabilirler. Ancak istediği kadarını web üzerinde istediği kadarını da kendi bilgi tabanında sunabilir. Bu nedenle etmenlerin Web üzerindeki bağlı verileri, Diğer etmenlerin bilgi tabanlarındaki verileri, Birden fazla veriseti üzerinde bağlı verileri, sorgulamaları gerekmektedir. 25
Etmenlerin Kaynakları Etmenler Üzerinden Sorgulaması Bir kaynak tek bir etmene aittir ve kaynak ile ilgili tanımlamalar sadece bu etmenin bilgi tabanındadır. Bu durumda kaynak ile ilgili tanımlamalar kaynağın sahibi etmen sorgulanarak bulunabilir. Ancak hangi etmenin bunun için sorgulanması gerektiği bilinmelidir. SEAGENT kaynak URI'lerinin yapısı kaynağın hangi etmene ait olduğu, kaynağın, etmenin bilgi tabanında nerede kayıtlı olduğu ile ilgili bilgileri içeren bir yapıdadır. Bu sayede hangi etmenle ilgili iletişime geçileceği bilinir ve kaynaklar sorgulanabilir. 26
Etmenlerin Kaynakları Etmenler Üzerinden Sorgulaması 27
Etmenlerin Kaynakları Etmenler Üzerinden Sorgulaması 28
Etmenlerin Kaynakları Etmenler Üzerinden Sorgulaması SEAGENT etmenlerinin kaynakları sorgulamasının planlarının görüldüğü Get Resource Scenario şeklinde istemci ve sağlayıcı rolünün davranışları sergilenmektedir. Burada kendisine istem gönderilmiş bir etmen sağlayıcı rolünü oynarken karşılaştığı başka bir kaynak çözümlemesi için istemci rolünü oynamaya geçebilir. Bu çözümde, kaynaklar bir seviye ilişkili oldukları kaynakları getirmek ya da tamamını getirmek olmak üzere iki şekilde sorgulanabilmektedirler. 29
Etmenlerin Kaynakları Etmenler Üzerinden Sorgulaması Kaynaklar tek bir etmenin bilgi tabanında tanımlıdırlar ancak, bir veya daha fazla etmenin bilgi tabanında kullanılıyor olabilirler. Yani kaynak URI'si <s,p,o>'larda object konumunda diğer etmenlerin bilgi tabanlarında bulunabilirler. Bu gibi durumlarda kaynakların kullanıldığı verilerin aranması için bu kaynakları içeren tüm etmenlerin bilgi tabanlarının sorgulanması gerekir. SEAGENT etmenlerinin bu sorunu çözmesi için daha sonra bahsedilecek olan void[17](vocabulary of Interlinked Datasets) ontoloji dökümanlarından faydalanması düşünülmektedir. 30
Etmenlerin Kaynakları Web Üzerinden Sorgulaması Etmenler, hem web üzerinde bulunan verisetlerini hem de etmenlerin web üzerine sundukları verisetlerini sorgulayabilmeleri için web üzerinden kaynak sorgulamaları yapmalıdırlar. Web üzerindeki verisetlerinin sorgulanması için SPARQL uç noktaları denilen servisler sunulmaktadır. Bir kaynağın tek bir yerde tanımlı olduğunu söylemiştik. Kaynağın <s,p,o> üçlülerinde subject konumunda olduğu verileri bulmak yani kaynak tanımlamalarına erişmek için daha önce bahsedilen URI yapılarında sözü geçen RDF dökümanlarının URI'lerine erişilebilir. Ancak kaynağın <s,p,o> üçlülerinde object konumunda olduğu veriler birden fazla verisetinde bulunabilir. Bunun için tüm bu verisetlerinde aranılan olası veri(ler) var olabilir. 31
Etmenlerin Kaynakları Web Üzerinden Sorgulaması Verisetlerinin sorgulanması için sorgulanacak verisetlerinin bulunması gerekmektedir. Bu da anlamsal web'e uyum için gerekli olan arama mekanizmasının var olmasını gerektirmektedir. Sindice, swoogle gibi anlamsal arama motorları, void gibi verisetlerini tanımlayan ontoloji dökümanları, CKAN gibi verisetlerinin SPARQL uç noktası adreslerinin kayıtlarının tutulduğu araçlar ve servisler verisetlerinin bulunması amacı ile gerçekleştirilmiştir. 32
Etmenlerin Kaynakları Birçok Veriseti Üzerinden Sorgulaması Verilerin, sorgunun içeriği gereği birden fazla veriseti üzerinden sorgulanması gerekebilir. Örneğin hem bir etmenin bilgi tabanında hem de web'de yayınlanan bir verisetinde yer alan satış kayıtları üzerinde sorgulama yapılmak istenebilir. Sorgulamaların tek tek yapılması daha sonra birleştirilmesi zaman kaybı ve tutarsızlıklara yol açabilir. Ana fikir, sorguların alt sorgulara parçalanması ve sonuçların birleştirilip kullanıcıya sunulmasıdır[10]. 33
Etmenlerin Kaynakları Birçok Veriseti Üzerinden Sorgulaması Bunun için tek bir sorgu sanki tek bir veri seti üzerinde çalıştırılıyormuş gibi sorguyu çalıştırabilen DARQ, SemWIQ gibi sorgulama motorları vardır. DARQ ve SemWIQ, SPARQL sorgulamaları üzerinden bazı kısıtlamalar içerirler[9] ve bu gibi sorgulama motorları hangi verisetleri üzerinde çalıştırılacaklarının bilinmesini gerektirir. SEAGENT etmenleri, belirtilen verisetleri üzerinde sorguları çalıştırabilmek için Jena framework'ünün ARQ sorgulama motorunu kullanmaktadır. Diğer sorgulama motorları ile çalışmanın avantajları araştırılmaktadır. 34
Etmenlerin Bağlı Veri Setlerini Araması Etmenlerin, sorgulamaları tam olarak yapabilmeleri ve anlamsal web ortamına ayak uydurmaları için verisetlerinin keşfedilmesine ihtiyaç duyduğunu belirtmiştik. Bunun için başlıca yöntemler; Arama motorları(sindice, swoogle, vb...) Veriseti tanımlama ontolojiler(void, vb...) Verisetleri uç noktaları kayıtçıları(ckan,vb...) Sorgulardaki URI'lerle ilişkili kaynak dökümanlarının incelenmesi(link Traversal) 35
Etmenlerin Bağlı Veri Setlerini Araması Arama Motorları Sindice ve swoogle gibi arama motorları aranılan bir kaynak URI'sinin bulunduğu RDF dökümanlarının sonuçlarını döndürür. Bu sonuçları döndürürken herhangi bir sıralama ya da öncelik gözetmez. Tamamen rast gele sıralama yapar. Bu yüzden tam bir çözüm önermezler. 36
Etmenlerin Bağlı Veri Setlerini Araması VoiD VoiD dökümanları ile verisetlerinin sahiplerinin verisetlerini tanımlayabilirler. İçeriklerin ne ile ilgili oluğu, erişme mekanizmaları(sparql endpoint, API vs), lisans türü, kaynağı, diğer verisetlerine nasıl bağlanacağını, içerisinde hangi vocabulary'ler kullanıldığı ve içeriklerle ilgili istatistikler tanımlanabilir. http://www.w3.org/tr/void/ adresinde void tanımlamalarının nasıl yapılacağına dair örnekler verilmiştir. Büyük verisetlerinin ne ile ilgili oldukları bu küçük tanımlama dökümanları incelenerek çok kısa sürelerde aranan verilerin bu veriseti üzerinde aranıp aranmayacağına dair fikir 37 elde edilebilir.
Etmenlerin Bağlı Veri Setlerini Araması VoiD Verisetlerini tanımlayan VoiD dökümanları iki şekilde bulunabilir: Veriseti içerisinde eğer varsa <s,void:indataset,o> üçlüsünün objecti void dökümanının URI'sidir. Well-known URI yöntemi : Örneğin www.example.com'da sunulan void dökümanının URI'si genellikle www.example.com/.well-known/void şeklindedir. SEAGENT etmenlerinde bu yaklaşımın uygulanması için her etmenin bilgi tabanı için bir void dökümanı yaratılması ve etmenlerin bilgi tabanlarının içine tanımlandıkları void dökümanının URI'sini içeren bir üçlü tanımlanması planlanmaktadır. 38
Etmenlerin Bağlı Veri Setlerini Araması CKAN Mondeca tarafından sunulan bir SPARQL uç noktası hizmet zamanı servisi ile CKAN[11] denilen tüm SPARQL uç noktalarını kayıtlarını tutan bir ağda bulunan kayıtlar incelenebilir[4]. Yaratılan verisetleri ile ilgili bilgiler bu ağa kaydedilebilir. Ancak buraya kayıt yaptırılmazsa yine tam bir çözüm sağlanamaz, ama pek çok veriseti ile ilgili kayıtları bulundurduğu için yine de kullanışlı olabilir. 39
Etmenlerin Bağlı Veri Setlerini Araması Link Traversal Sorgu içerisindeki verilerin hangi verisetlerinde olduğu bilinmeden sadece verilerin URI'lerin tanımlandığı verisetlerinin aranmasına dayalı çözümdür[10]. Bazı sorgular için tam bir çözüm sağlamayabilir. Select?c?u WHERE { <http://mymovie.db/movie2449 > mov:filming_location?c.?c geo:statistics?cstats.?cstats stat:unemprate?u. } sorgusu için tam bir çözüm sağlar. Çünkü sorgunun cevabı için sadece kaynak dökümanlarının keşfedilmesi yeterlidir. 40
Etmenlerin Bağlı Verileri Görüntülemesi SEAGENT etmenlerinin kaynaklarını görüntüleyebilmeleri ve herhangi bir alana özgü kaynakları yaratabilmeleri için yeniden kullanılabilir esnek araçlar geliştirildi. Bu araçlar sayesinde etmenlerin sahip oldukları kaynak niteliğindeki veya literal niteliğindeki, bir veya birden fazla olabilen tüm özellikleri görüntülenebilmektedir. Bir kaynağın görüntülenmesi için geliştirilen başlıca bileşenler: DatatypePropertyViewer : Literal olan RDF özelliklerinin görüntülenmesini sağlar. DatatypePropertyListViewer : Literal olan birden fazla RDF özelliğinin görüntülenmesini sağlar. 41
Etmenlerin Bağlı Verileri Görüntülemesi 42
Tamamlanan Çalışmalar Etmenlerde bağlı veri yapılarının tanımlanması ve kullanılması Etmenlerin bağlı verileri depolaması için bir triple store yapısı. TripleStoreManager gerçekleştirildi. IndividualViewer denilen bağlı verilerin görüntülenmesi ve yaratılması için bir SemanticSwing ve SemanticUnit kütüphanaleri geliştirildi. Etmen-Etmen sorgulaması(sorgulanacak etmen belirlenebiliyor ise) Etmen-Web Sorgulaması(Sorgulanacak veriseti biliniyor ise) Etmenin Web Üzerinde Dağıtık Sorgular Çalıştırması(Sorgulanacak verisetleri biliniyorsa) 43
Tamamlanacak Çalışmalar Yeniden URI tasarımı : Etmenin kaynaklarının web'e açılması için URI yapısında bulunan @ işaretinin kaldırımlası, kullanılan URI çözümünün tartışılması Etmenin Web'e açılması : Joseki server kullanılarak kaynakların dışarıya açılması Etmenin Web'e sunulan verilerinin sorgulanması Etmenin dağıtık(etmen+web) sorgular çalıştırabilmesi Hem Web'de hem de etmenlerde sorgulanacak verisetlerinin belirlenebilmesi : VoiD yaklaşımı gerçekleştirilmeye çalışılacak Durum çalışması 44
REFERANSLAR [1] Berners-Lee, T. (2006). Linked Data - Design Issues. Retrieved July 23, http://www.w3.org/designissues/linkeddata.html [2] Berners-Lee, T. (2000): Weaving the Web: The Past, Present and Future of the World Wide Web by its Inventor. London, Texere. [3] Christian Bizer, Tom Heath, and Tim Berners-Lee. Linked data - the story so far. International Journal on Semantic Web and Information Systems (IJSWIS), 2009. [4] http://www.w3.org/wiki/sparqlendpoints [5] http://www.w3.org/rdf/ [6] Leo Sauermann, Richard Cyganiak, and Max Völkel. Cool URIs for the semantic web. Technical Memo TM-07-01, DFKI GmbH, Deutsches Forschungszentrum f ür Künstliche Intelligenz GmbH Postfach 2080 67608 Kaiserslautern, February 2007. 45
REFERANSLAR [7] http://en.wikipedia.org/wiki/resource_description_framework. [8] A Develepoer's Guide to the Semantic Web, Liyang Yu, ISBN 978-3- 642-15969-5. [9] Jan Zemanek, Simon Schenk, Vojtech Svatek, Optimizing SPARQL Queries over Disparate RDF Data Sources through Distributed Semi-joins, 2008. [10] http://www4.wiwiss.fu-berlin.de/bizer/pub/linkeddatatutorial/ [11] http://ckan.net/ [12] Olaf Hartig, Christian Bizer, and Johann-christoph Freytag. Executing SPARQL queries over the web of linked data, 2009. [13] Bastian Quilitz and Ulf Leser. Querying distributed RDF data sources with SPARQL. pages 524 538. 2008 46
REFERANSLAR [14] Eyal Oren, Renaud Delbru, Michele Catasta, Richard Cyganiak, and Giovanni Tummarello. Sindice.com: A document-oriented lookup index for open linked data. International Journal of Metadata, Semantics and Ontologies, 3. [15] T. Berners-Lee, J. Hollenbach, Kanghao Lu, J. Presbrey, and Mc Schraefel. Tabulator redux: Browsing and writing linked data, 2008. [16] http://openjena.org/wiki/sdb [17] Ian C. Millard, Hugh Glaser, Manuel Salvadors, Nigel Shadbolt, Consuming multiple linked data sources : Challenges and Experiences, 2010. 47