=Paper=
{{Paper
|id=None
|storemode=property
|title=Bağlı Veri Entegrasyonu İçin Bir Masaüstü Uygulama Mimarisinin Medikal Alanda Geliştirilmesi
|pdfUrl=https://ceur-ws.org/Vol-1072/submission10.pdf
|volume=Vol-1072
|dblpUrl=https://dblp.org/rec/conf/uyms/SimsekE13
}}
==Bağlı Veri Entegrasyonu İçin Bir Masaüstü Uygulama Mimarisinin Medikal Alanda Geliştirilmesi==
https://ceur-ws.org/Vol-1072/submission10.pdf
Bağlı Veri Entegrasyonu İçin Bir Masaüstü Uygulama
Mimarisinin Medikal Alanda Geliştirilmesi
Umutcan Şimşek, Rıza Cenk Erdur
Ege Üniversitesi Bilgisayar Mühendisliği Bölümü, Bornova, İzmir
s.umutcan@gmail.com, cenk.erdur@ege.edu.tr
Özet. Farmakolojiye yönelik araştırma süreçlerinde yaşanan en büyük problem-
lerden birisinin bir aktif madde ile ilgili olarak internet üzerinde geleneksel ar-
ama motorlarıyla yapılan aramalardan dönen sonuçların, işe yararlığa göre
süzülüp entegre edilmesi olduğu görülmüştür. Bu sorunun önüne geçmek için
bağlı verinin gücünden yararlanan ve yüksek erişilebilirlikli bir uygulama
geliştirilmiştir. Ege Üniversitesi İlaç Araştırma ve Farmakokinetik Geliştirme-
Uygulama Merkezi (ARGEFAR) danışmanlığında geliştirilen bu uygulama,
bağlı açık ilaç verisi bulutu üzerindeki verilerin, bir masaüstü uygulamasında
entegrasyonu için geliştirilen bir mimariye dayanmaktadır.
Veri erişiminde güncelliğin sağlanması için SPARQL uçnoktalarında sorgu
dağıtımı erişim deseni kullanılmıştır. Bu desen her zaman güncel veriyi
getirmesine karşın, erişilebilirlik sorunlarına sahip olduğundan, mimaride,
desen üzerinde önbellekleme ve indeksleme gibi mekanizmalar geliştirilmiştir.
Mimarinin, nesneye dayalı programlama paradigmasına dayalı esnek yapısı
sayesinde yeni veri kaynaklarıyla genişlemeye uygun olduğu görülmüştür.
Ayrıca paralelleştirmeye uygun yapısı sayesinde, dağıtık olarak da çalıştırıla-
bileceği düşünülmektedir. ARGEFAR araştırmacılarıyla yapılan testlerde,
sadece isminin bir kısmı dahi bilinen bir aktif madde ile ilgili gerekli bilgilere
ulaşımın oldukça kolaylaştığı gözlemlenmiştir.
Anahtar Kelimeler. RDF, SPARQL, veri entegrasyonu, bağlı veri, medikal
bilişim
1 Giriş
Birçok alandaki araştırma-geliştirme çalışmalarının önemli bir bölümünü, verinin
değişik kaynaklardan toplanması ve bu toplanan verinin entegre edilmesi oluşturmak-
tadır. Bu süreçteki en büyük problemlerden birisi de, geleneksel arama motorlarıyla
yapılan aramalar içinden, işe yarar verilerin süzülmesi ve entegre edilmesidir.
Günümüz interneti, dökümanların birbirlerine bağlanmasından oluştuğundan, arama
motorları sadece metin tabanlı arama yapmakta, direkt olarak aranılan kavramı değil,
kavramın içinde bulunduğu dökümanı büyük ölçüde anlamsal olarak incelemeksizin
bulmaktadır [15].
Bu çalışmada, bağlı verinin gücünü kullanarak, farmakoloji araştırmacılarının uy-
gun veriyi bulma ve birleştirme sürelerini kısaltmaya, araştırma sürecinin etkinliğini
artırmaya yönelik bir uygulama geliştirilmiştir.
Bağlı veri, temel olarak farklı kaynaklardaki verinin anlamsal çıkarımlar yapmaya
uygun şekilde bağlanmasıyla oluşur. HTML dökümanlarına dayalı web dökümanların
birbirine bağlanmasıyla oluşurken; bağlı veri, veriyi RDF (Resource Description
Framework) [2] formatında dökümanlarda tutar ve dökümanlar yerine verinin
kendisini yani kavramları bağlar [5].
Bağlı verinin en somut uygulaması Linking Open Data Project'tir (Açık Veriyi
Bağlama Projesi) [5]. İnternet üzerinde, çeşitli formatlarda açık olarak yayınlanan
verinin, Tim Berners Lee'nin öne sürdüğü “5 yıldız kuralı”na [4][9] uydurularak birbi-
riyle bağlanmasını hedefleyen bu projede oluşan veri bulutu her gün giderek
büyümektedir. 2009 yılında bile bu bulut milyarlarca kayıt içermekteydi. Açık bağlı
veri bulutunda 2011 yılında yer alan veri kümeleri Şekil - 1'deki gibidir [11].
Şekil 1. 2011 yılında açık bağlı veri bulutu
Bu çalışmada, farmakoloji araştırmaları için geliştirilen uygulamada, bağlı açık
veri bulutunun bir parçası olan Linked Open Drug Data (LODD)1 Verisi bulutunda
yer alan veriden yararlanılmıştır (Şekil - 2) [14]. Bu bulut, internette dağınık olarak
bulunan onlarca biyomedikal veri kümesini birbirine bağlamaktadır. Örneğin, Aspirin
1 Bağlı Açık İlaç Verisi
ilacı ile ilgili kimyasal yapı verisi ve klinik deney verisi bu bulut kullanılarak farklı
kaynaklar üzerinden getirilebilir [14].
Şekil 2. LODD (Linked Open Drug Data) bulutu
Bu çalışma kapsamında geliştirilen uygulama, LODD üzerinde ARGEFAR
danışmanlarıyla belirlenen veri kümeleri üzerindeki verileri bir masaüstü uygula-
masında entegre etmektedir. Uygulama, başka alanlara özgü masaüstü bağlı veri uy-
gulamaları için de kullanılabilecek katmanlı bir mimari önermektedir.
Bildiri şu bölümlerden oluşmaktadır: Bölüm 2'de bu çalışma ile ilgili daha önceden
gerçekleştirilen çalışmalar kısaca incelenmiştir. Bölüm 3'te uygulamanın gerçekleşti-
rimi ve mimarisi açıklanmıştır. Bölüm 4'te ise uygulamanın sonuçları tartışılmıştır.
2 İlgili Çalışmalar
2.1 OpenPHACTS
OpenPHACTS projesi, üniversitelerin, araştırma kurumlarının ve özel sektörden
birçok firmanın işbirliği ile hazırlanmış ve hayata geçirilmeye başlanmıştır. Proje,
farmakoloji araştırmalarında ortaya çıkan veriye ulaşım ve ulaşılan verinin kullanıla-
bilecek hale getirilmesi problemini bağlı veriden yararlanarak ortadan kaldırmayı
amaçlar. [6]
OpenPHACTS kapsam itibariyle oldukça geniş bir alana hitap eder, ilaçların far-
masötik özelliklerinin yanında kimyasal yapılarıyla ilgili de bilgi sunar. Open-
PHACTS'in kullanıma sunduğu internet üzerinde çalışan OPS [6] platformu, kendi
başına bir uygulama olmaktan ziyade, geliştirilecek bağlı veri uygulamalarına bir
altyapı hazırlamaktadır. Utopia Documents isimli makale zenginleştirme uygulaması
buna örnek olarak gösterilebilir [1].
Şekil 3. OPS mimarisi[6]
OPS platformu, yedi bileşenli bir mimari kullanmayı seçmiştir. Şekil - 3'te görüle-
bilecek, dört katmana yayılan bu yedi bileşen şu şekildedir [6]:
1. Data Sources (Veri Kaynakları): Bu bileşen, mevcut RDF verikümelerinin
bulunduğu katmandır. Enzimlerden, diğer kimyasal bileşeklere, birçok veriyi sunan
UniProt[12], LODD[10] ve Bio2RDF[3] kaynakları bu katman aracılığı ile
kullanılmaktadır.
2. Linked Data Cache (Bağlı Veri Önbelliği): Bu bileşen, güvenilirlik ve performans
açısından iyileştirme yapılması amacıyla kullanılan veri kümelerinin tamamıyla
yerel olarak saklanması amacıyla kullanılmaktadır. SPARQL sorgularının sunucu-
ları yoracağı varsayılarak tüm sorgulama işlemlerinin burada yapılması öngörül-
müştür.
3. Identifier Resolution Service (Kimlik Çözümleme Servisi): Bu katman, serbest
metin arama ile yapısal sorguların birbirinden ayrıldığı katmandır.
4. Identifier Mapping Service (IMS): Eşitliğin bağlam bağımlı olmasından yola
çıkarak, iki farklı veri kaynağından gelen aynı kavrama ait verilerin eş olup olma-
dığını kontrol eden bileşendir.
5. Domain Specific Services (Alana Özgü Servisler): OPS, alana özgü servislere
örnek olarak, farklı veri kaynaklarındaki küçük kimyasal bileşenleri, yapılarına
göre birbirlerine entegre edip eşsiz bir kimlik numarası veren ChemSpider isimli
servisten yararlanmaktadır.
6. Core API (Çekirdek API): OPS platformunun ilk sürümlerinde yer almayan bu
katman, SPARQL sorgularını, OPS üzerinde geliştirilen uygulamalardan soyutlar.
Uygulama geliştiricilere önceden tanımlanmış yöntemler sunarak, geliştiricilerin
düşük performanslı sorguları çalıştırmalarının önüne geçer. Bu katman, uygulama
geliştiricilerin sisteme dahil oldukları katmandır.
7. User Interfaces/Applications(Kullanıcı Arayüzü/Uygulamalar)
Mimarinin diğer bileşenleri ile ilgili ayrıntılı bilgiye [6] kaynağından erişilebilir.
2.2 TripleMap
TripleMap2, ağırlıklı olarak sağlık alanında olmakla birlikte, değişik veri kaynak-
larındaki verinin grafik olarak gösterilmesini sağlayan bir internet uygulamasıdır. Bu
uygulama, kavramları simgelerle temsil edip kavramlar arasındaki bağları etiket-
leyerek bir çizge düzeninde gösterir [14]. Bir veri kümesinde neyin neyle bağlı
olduğunu görmek için kullanışlı bir uygulamadır.
2.3 Tartışma
OPS platformu, verinin anlık olarak güncel bir şekilde getirilmesinde bazı sorunlar
yaşayabilmektedir. Çünkü Şekil - 3'te görülen mimarideki Linked Data Cache
bileşeni, kullanılan veri kümelerindeki tüm verinin OPS sunucularına alınmasıyla
oluşur ve sorgular bu sunucular üzerinde çalışır. Bu da programın zaman zaman gün-
cel olmayan veri ile çalışmasına neden olabilir. Bunların dışında, OPS platformunun
kimlik çözümleme servisi ve bazı eşleştirme mekanizmaları oldukça gelişmiştir. Yine
de OPS platformu, bir uygulamadan ziyade bir altyapı sunduğundan, bu çalışma
kapsamında geliştirilen uygulama ile işlevsel açıdan birebir karşılaştırmak pek
mümkün değildir. Zira bu çalışma kapsamında geliştirilen uygulamada, ilerleyen
sürümler OPS platformunun Core API bileşeninden yararlanabilir.
TripleMap uygulaması oldukça başarılı bir görselleştirme sunmanın yanında, ara-
ma sonuçlarına cevap vermede eksiklikleri görülmüştür. Bu çalışma kapsamında
geliştirilen uygulamada yapılan Propranolol araması ilacın farmakolojik özelliklerine
dair verilerini getirirken, TripleMap'te yapılan aramada zaman zaman sonuç
gelmemekte, zaman zaman da sadece belirli veriler dönmektedir. Bunun dışında, Tri-
pleMap'in mimarisine dair bir içerik bulanamadığından iki çalışma bu açıdan
karşılaştırılamamaktadır.
2 http://www.triplemap.com
3 Gerçekleştirme
Bir bağlı veri uygulamasında, en önemli karar noktası, bağlı veriye nasıl
erişileceğidir. Bağlı veri araştırmacılarının genel olarak kabul ettiği üç erişim deseni
bulunmaktadır: Emekleme Deseni, Yerinde Çözümleme Deseni, Sorgu Dağıtım
Deseni [9].
Emekleme Deseni, temel olarak günümüz arama motorları ile benzer şekilde
çalışır. Bu desende tüm veri uzayı gezilerek sonuçlar bir yerde depolanır ve arama
sonuçları bu depolanan verilerden getirilir. Her ne kadar büyük veri kümeleri için
uygun olsa da güncel olmayan veriyle çalışma ihtimali oldukça yüksektir. Bir diğer
desen olan Yerinde Çözümleme deseni de emeklemeye benzerdir fakat emekleme
işlemi sadece ihtiyaç duyulduğunda yapılır. Bu desenin de performansı işlemler
karmaşıklaştıkça önemli ölçüde düşer.
Üçüncü ve son desen ise Sorgu Dağıtım Deseni'dir. Bu desen, SPARQL sorgu-
larının arama ile eş zamanlı olarak çevrimiçi SPARQL uçnoktalarına dağıtılması ile
çalışır. Ulaşılan veri sürekli güncel olmasına rağmen, uçnoktaların zaman zaman per-
formans sorunları yaşamaları ve karmaşık sorgularda, özellikle serbest metin aramada
çabuk sonuç döndürememeleri sebebiyle sorgu etkinliği önemli ölçüde düşebilmekte-
dir. Gerçekleştirilen uygulama, indeksleme ve kalıcı katman oluşturma(önbellekleme)
gibi yöntemler kullanarak sorgu dağıtım desenin iyileştirilmesini amaçlar.
3.1 Veri Kümeleri
Uygulama gerçekleştirilirken, ARGEFAR danışmanlarıyla birlikte ilk prototiplerde3
kullanılmak üzere dört adet veri kümesi seçilmiştir.
DBPedia4 http://dbpedia.org: Wikipedia'nın bağlı veri versiyonudur. Neredeyse
tüm wikipedia verisine bağlı veri formatında erişilebilir, verilerin diğer veri kümel-
eriyle bağlar da kurulmuştur.
Drugbank: Yaklaşık 5000 FDA onaylı ilaç ile ilgili gerek farmakolojik gerek bi-
yolojik gerekse kimyasal bilgiyi sunan güncel bir veri kaynağıdır [10].
DailyMed: Amerikan Ulusal Tıp Kütüphanesi tarafından yayınlanan FDA onaylı
ilaçların prospektüs bilgilerini yayınlayan bir veri kaynağıdır. Bu veri kaynağı RSS
beslemeleri kullanılarak bir üniversite tarafından bağlı veri olarak yayınlanmak-
tadır [10].
LinkedCT: Dünya üzerinde tamamlanmış veya hala süren klinik ilaç deneylerinin
yayınlandığı ClinicalTrials.gov sitesinin bağlı veri olarak yayınlanmış halidir. 158
ülkeden 60000 üzerinde klinik deney verisi yer almaktadır [8].
3 Prototipin kaynak koduna https://github.com/sumutcan/Pharmeshup adresinden
ulaşılabilir.
4 http://www.dbpedia.org
3.2 Yazılım Mimarisi
Geliştirilen üç katmanlı mimari Şekil - 4'te görülmektedir. Mimari, en üstte
kullanıcıyla etkileşimin sağlandığı arayüz katmanı, ortada çoklu iş parçacıklı alt kat-
man ile birlikte uygulamanın asıl yükünü taşıyan iş katmanı ve en altta da veri
kaynaklarının bulunduğu veri katmanından oluşur.
Şekil 4. Geliştirilen katmanlı mimari
Kullanıcı Katmanı. Bu katman kullanıcı ile uygulamanın etkileşime girdiği kat-
mandır (Şekil - 5). Kullanıcıya sunulan veriler, bu katmanda Genel Bilgiler, Farma-
kokinetik, Farmakodinamik ve Klinik Deneyler olarak dört sekme halinde
gösterilmektedir.
Genel Bilgiler sekmesinde, aktif madde ile ilgili kısa açıklamalar ve prospektüs
bilgileri gibi bilgiler yer almaktadır.
Farmakokinetik sekmesinde, canlı metabolizmasının ilacın aktif maddesine ne
yaptığı ile ilgili bilgiler yer almaktadır. Emilim, vücuttan uzaklaştırılma süresi gibi
bilgiler bu kategoriye girer.
Farmakodinamik sekmesinde ise, ilacın canlı metabolizmasına ne yaptığı ile ilgili
bilgiler verilmektedir.
Klinik Deneyler sekmesi de, o aktif madde ile ilgili klinik deney verilerinin güncel
bir şekilde ClinicalTrials.gov kaynağından getirilip kullanıcıya sunulduğu sekmedir.
Şekil 5. Kullanıcı arayüzünden bir ekran görüntüsü
İş Katmanı. Bu katman, iki tanesi çoklu iş parçacıklı alt katmanda yer almak
üzere, toplamda beş bileşenden oluşur. Bu bileşenlerden ilki olan İlaç Verisi Denet-
leyicisi, GRASP [13] desenlerinde Controller'a karşılık gelen bileşendir ve uygula-
manın kullanıcı arayüzünden diğer katmanlara çıkış noktasını oluşturur.
Ögeler bileşeni, iş katmanında gerçekleşen işlemlerde bazı gerekli verilerin tu-
tulması için yaratılan sınıfları içerir. Bu bileşendeki en önemli sınıf, arama yapılan
karakter katarını bellekteki indekslenen elemanlarla eşleştirip bir RDF kaynağına
dönüştüren sınıftır.
Veri Setleri bileşeni de, farklı veri kümelerini temsil eden sınıfları içerir. Nesneye
dayalı paradigma ile sağlanan esnek yapı sayesinde yeni bir veri kümesi eklemek,
neredeyse sadece yeni bir sınıf oluşturmak kadar basitleşmiştir.
Bu katmanda yer alan Çoklu İş Parçacıklı Alt Katman, uygulamanın veri erişimi,
indeksleme, önbellekleme gibi işlemlerini yaparken hem performansı artırması hem
de yapılan yoğun işlemlerin kullanıcının aramalarını bölmemesi için oluşturulmuştur.
Bu alt katmanda iki bileşen yer almaktadır:
İndeksleme Yardımcısı: Bu bileşen, belirlenen aralıklarda, veriye ulaşım için anah-
tar olan verileri, SPARQL uçnoktalarına yaptığı sorgularla bir JSON5 dosyasında
indeksler. Uygulamanın şu anki halinde yaklaşık 15000 ilaç verisi ve bunların
eşdeğerleri indekslenmektedir. Kullanıcı tarafından girilen arama ifadesi, bu JSON
dosyasının belleğe eşlenmiş hali üzerinde aranarak bulunan RDF kaynakları dö-
ndürülür. Bu RDF kaynakları aracılığı ile istenen ilacın bağlı veri bulutu üzerindeki
5 Nesneye dayalı paradigmaya göre tasarlanmış bir veri gösterim formatıdır.
bilgilerine daha hızlı bir şekilde ulaşılır. Tablo - 1'de, indeksleme işleminin doğru-
dan SPARQL uçnoktaları üzerinde yapılan serbest metin aramasına göre getirdiği
iyileştirme açıkça görülmektedir.
Tablo 1. DBPedia verisi üzerinde, isminde “pro” ifadesi geçen aktif maddelerin ve eşdeğerler-
inin aranması
SPARQL Uçnoktası Tepki Süresi İndeksleme Mekanizması Tepki Süresi
32 saniye 0.3 saniye
Bağlı Veri Erişimi: Bu katmanda bağlı veriye erişim gerçekleşir. Sorgu perfor-
manslarının ve erişilebilirliğin artırılması, internet bağlantısına bağımlılığın
azaltılması için oluşturulan kalıcı katmana (önbellek) erişim de yine bu katmanda
gerçekleştirilir. Strateji tasarım deseni ile oluşturulan bu bileşende (Şekil - 6),
çalışma zamanında SPARQL uçnoktalarından ulaşılan bir aktif maddeye ait alt
çizge arkaplanda yerel üçlü deposuna kaydedilir. Uçnoktaların ulaşılamaz olduğu
zamanlarda strateji tasarım deseni ile oluşturulan yapı yerel depoya ulaşarak daha
önceden önbelleklenmiş veriyi getirir. Böylece daha önce bir kere ulaşılmış veri,
uygulamanın kullandığı her an erişilebilir olur.
Kalıcı katman aynı zamanda basit bir kimlik çözümleme servisi görevi de görür. Bağlı
veride, iki RDF kaynağı owl:sameAs özelliği ile birbirine bağlanabilir. Bu özellik iki
kaynağın tüm yönleriyle eş olduğunu gösterir [7]. Fakat açık bağlı veri bulutunda
owl:sameAs linklerine her zaman güvenmek doğru olmaz. Örneğin Metamizole etken
maddesi için, DBPedia kaynağı, Drugbank kaynağı ile owl:sameAs aracılığı ile
bağlanmıştır. Halbuki, isim olarak aynı da olsalar, DBPedia'daki Metamizole, met-
amizol maddesinin sodyum tuzudur. Bu durum maddenin kimyasal formülünü
değiştirdiğinden, iki kaynaktaki RDF ifadelerinin owl:sameAs ile bağlanabilmesi
mümkün değildir. Bu nedenle, bir etken madde ile ilgili farklı kaynaklardan gelen alt
çizgeler, isimlendirilmiş çizgeler olarak tutularak verinin kaynağının da belli olması
sağlanır [16].
Çoklu İş Parçacıklı Alt Katman'da, geleneksel Thread yapısının yanı sıra, Java 5.0
ile birlikte gelen Callable API'si6 de kullanılmıştır. Bu API, Thread'den farklı olarak,
iş parçacıklarından sonuç dönmesine ve zaman aşımı gibi çeşitli istisnai durumların
yakalanmasına olanak sağlar.
6 http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Callable.html
Şekil 6. Veri erişimi için kullanılan strateji tasarım deseni UML şeması
Veri Katmanı. Bu katmanın bir yerel bir de uzak tarafı vardır. Yerel tarafta, yani
uygulama tarafında, indekslenen anahtar verilerin tutulduğu JSON dosyası ve
önbelleklenen ilaç verisinin tutulduğu yerel üçlü deposu; uzak tarafta ise verilerin
getirildiği SPARQL uç noktası bulunmaktadır.
4 Sonuç
Geliştirilen mimari, özellikle düşük yoğunluklu sorgularla veya büyük yoğunluklu
sorguların daha küçük parçalara dağıtılabildiği sorgularla çalışacak, masaüstü bağlı
veri uygulamaları için oldukça kolay uygulanabilir, genişleyebilir ve etkin bir jenerik
çözüm ortaya koymuştur. Zira Veri Setleri bileşeninde her veri kümesini bir Java
sınıfı temsil etmektedir ve tüm veri kümeleri ortak bir soyut sınıftan türediğinden,
yeni veri kümeleri sadece bu sınıf implemente edildikten sonra soyut yöntemlerin
implemente edilmesiyle eklenebilir. Aynı şekilde, sorgular da ayrı depo sınıflarında
tutulduğundan; mimari, farklı veri kümeleri ve sorgular tanımlanarak farklı alanlara
da uygulanabilir.
Mimarinin paralel yapısının, işlemleri tamamen veya kısmen dağıtık sistemler
üzerinde gerçekleştirilebilmeye uygun olacağı düşünülmektedir. Şekil - 4'te görülen
mimaride, çoklu iş parçacıklı alt katmandaki bileşenler birbirlerinden büyük ölçüde
bağımsız olduklarından, farklı sistemlere dağıtılıp farklı stratejiler (mesaj gönderme,
paylaşılan bellek gibi) ile beraber çalıştırılabilecekleri öngörülmektedir.
Gerçekleştirilen uygulama, ARGEFAR araştırmacılarıyla yapılan ilk testlerden
olumlu sonuçlar elde etmiş, araştırma sürelerini kısalttığı görülmüştür.
Kaynaklar
1. TK Attwood, DB Kell, P McDermott, J Marsh, SR Pettifer and D Thorne. Utopia Docu-
ments: linking scholarly literature with research data. Pub Med, Bioinformatics, 41(5),
2010.
2. Dave Beckett, RDF/XML Syntax Specification, 2004.
3. F Bellau, MA Nolin, N Tourigny, P Rigault and J Morisette. Bio2RDF: towards a mashup
to bioinformatics knowledge systems. Journal of Biomedical Informatics, 41(5):706-716,
2008.
4. Tim Berners Lee, Linked Data – Design Issues, 2006.
5. Cristian Bizer, Tom Heath, Tim Berners-Lee and M. Hepp. Linked Data – The Story So
Far. International Journal on Semantic Web and Information Systems 5(3):1-22, 2009.
6. Alasdair J G Gray, Paul Groth, Antonis Loizou, Sune Askjaer, Christian Brenninkmeijer,
Kees Burger, Christine Chichster, Chris T Evelo, Carole Goble, Lee Harland, Steve Petti-
fer, Mark Thompson, Andra Waagmeester and Antohny J Williams. Applying Linked Data
Approach to Pharmacology: Architectural Decisions and Implementation. Semantic Web
Journal, 1(13), 2012.
7. Harry Halphin and Patrick J Hayes. When owl:sameAs isn't the Same: An Analysis of
Identity Links on the Semantic Web, ISWC, 6496, 2010.
8. Oktie Hassanzadeh, Anastasios Kementsietsidis, Lipyeow Lim and Min Wang. LinkedCT:
A Linked Data Space for Clinical Trials. CoRR, 2009.
9. Tom Heath and Cristian Bizer. Linked Data – Evolving the Web into a Global Data Space.
Morgan and Claypool Publishers, 1st edition, 2011.
10. Anja Jentzsch, Matthias Samwald and Bo Anderson. Linking Open Drug Data. Triplifica-
tion Challange, 2009.
11. Anja Jentzsch and Richard Cyganiak. The Linking Open Data Cloud Diagram – http://lod-
cloud.net
12. Michele Magrane and UniProt Consortium. UniProt knowledgebase: a hub of integrated
protein data. BMC Bioinformatics, 10(1):136+, 2009.
13. RM Noorullah. GRASP and GoF Patterns in Solving Design Problems. International Jour-
nal of Engineering and Technology, 1(3):196-205, 2011.
14. M Samwald, A Jentzsch, Christopher Boutton and Claus Stie Kalleso e. Linked Open Drug
Data for Pharmaceutical Research and Development, J Cheminform, 3(19), 2011.
15. John F Sequeda, Consuming Linked Data, 2010.
16. Chen Zhangjian and Qian Nen. Research of Semantic Web Publishing using Named
Graphs. In Semantics, Knowledge and Grid, page 132, 2005.