Indonesian J ournal of Ele c trical Engin eering and  Computer Sci e nce   Vol. 2, No. 1,  April 201 6, pp. 194 ~ 20 4   DOI: 10.115 9 1 /ijeecs.v2.i1.pp19 4-2 0 4        194     Re cei v ed Se ptem ber 21, 2015; Revi se d Jan uary 24,  2016; Accept ed Feb r ua ry  10, 2016   Challenges Over Two Semantic Repositories - OWLIM  and Allegro Graph      Paria Tajabo r 1 , Tara Raafat 2  1 Departme n t of Chemic al an d Process Eng i n eeri ng,  Surre y  Univers i t y , Gui l d ford, Unite d  K i ng dom   2 Mphasis, Un iv ersit y  of Surr e y , Avco S y stem s Ltd  Univers i ty of Surre y, Gu ildfor d , United  King dom   *Corres p o ndi n g  author, e-ma i l : p.tajabor @g mail.com         A b st r a ct   T he purp o se o f  this research  study is expl ori ng tw o kind of semantic re po sitories w i th regards t o   vario u s factors  to find  the  be st appr oach e s  that a n   artifici al ma na ger  c a n  us e  to prod uce ontol ogy i n  a   system   based  on their interac t ion, assoc i ation and res ear c h . To this end, as the best way to evaluate  eac h  system a nd co mp arin g w i th others is a naly s is, seve ral b e n ch marki ng ov er these tw o repos itories w e r e   exa m i ned. T h e s e tw o se ma nti c  rep o sitori es:  OW LIM and A l l egroGra ph w i l l   be th e  main  co re of th is stu d y .   T he ge nera l  o b jectiv e of this  study is to be  able to  cr eate  an efficie n t a nd cost-effecti v e mann er rep o rts   w h ich is requ ir ed to sup port d e cisio n   maki ng  in any lar ge e n terpris e .     Ke y w ords : OWLIM,   Allegr oGraph, RDF,  reason ing, s e mantic re pos itor y, sema nti c -Web, SPARQL,  Ontology, Query         Copy right  ©  2016 In stitu t e o f  Ad van ced  En g i n eerin g and  Scien ce. All  rig h t s reser ve d .       1. Introduc tion   It is necessa ry to point out  that in hug e  pr oje c ts,  gov ernm ent p r ocesse s; co mp anie s , IT   system s and  so forth the r e  are differe nt informat io n an d databa se s. These have variou s types  of  formats,  set s  of form s, d o cum ents an d re po sitori e s , with  not v e ry go od  ma nagem ent a n d   coo r din a tion.  It is obviou s  t hat ra mpa n t redun dan cy wi ll occu r  whe n   the  procedu re of devel opi ng  or re develo p i ng in the system, u s in g the sam e  information  but with di fferent forma t s,  architectu re s and model s,  is being p r o c e s sed. Basi cally, views  and attitude s toward s a wide   rang e  of information  as we ll as integ r ati on of  a ccu rat e  an d  com p l e te un de rsta nding  is difficult  and i n   som e  ca se s almo st imp o ssibl e  and  u n a c hie v able. On  th e othe r  han d  develo p ing  this  informatio n is really expen sive and tim e  con s umi ng;  hence the p r oble m  is ex ace r bate d  m o re   when this process  would take  place in lack of  interoperab ility, inconsist e nt designs and  redu nda nt system s. For th is rea s o n , different ki nd s o f  reposito r ie s are provided  to replace this  loss of i n formation a nd  data fra g me ntation  wi th  an  archite c ted ap pro a ch to inte grat ing,  developin g  a nd mana ging  informatio n throug hout the  system.    This  wo rk d e f ines two different  sema nt ic re po sitorie s  an d co mpa r ing them i n  term s of  different pa ra meters and f a ctors. To thi s  ai m, besi d e the backg round s an d exploring vari o u s   theorie s of rese arche s , a nalysi s  throu gh differ ent  asp e ct of asse ssm ent  is  done. In fact  th e   resea r ch obj ectives  ca n  be summa ri zed in th e fu lly assessm e nt of a  sele cted  sem anti c   repos i tories .       2. Backg rou nd and Moti v a tion   Over the la st  decade, a s   sema ntic  we b ha s  ra pidly  develop ed, the  effort of  system  develop ers h a s  also  signifi cantly in crea sed, e s pe cially  in field s  whe r e  no waday s  the imp o rtan ce  of sem antic  repo sito rie s  i s  e qual to  HTTP se rvers.  This ha s le d to succe ssful numb e rs  of  ontology st an dard s  a nd ro bust meta dat a and the  rol e  of these  st anda rd s is  a k in to the  rol e  o f   SQL to developing o r  sp re ading  DBMS relation s [1].   The ch ara c te ristics of a semantic repo sito ry are g e nerally simil a r to the data base  manag eme n t system s (DBMS) [2]. They handle  da ta  function s,  storin g info rmation, que rying   and m ana gin g  organi ze d  data. In fa ct, as Dimit r ov e in  his 20 1 0  conferen ce  pointe d  o u t, a   sema ntic rep o sitory combi nes featu r e s  of  inferen c e  engin e s a nd DBMS. However, the maj o r  Evaluation Warning : The document was created with Spire.PDF for Python.
                             ISSN: 25 02-4 752   IJEECS  Vol.  2, No. 1, April 2016 :  194 –  204   195 differen c e  b e t ween sem a n t ic  rep o sito ry and DBMS  is ontology, wh ich i s  just u s ed in  sema ntic  repo sito rie s  a s  se mantic  schema [3].  By developin g  a sy stem m any co nne cti ons   amon g la ngua ge s may  be lo st, whi c h co uld   lead to  erro r  pron e, la ck of  integration,  complexi ty an d finally  syste m  failures.  T h is i s sue  wou l d   be cata strop h ic when the r e are co mbi nation s  of  different sy ste m s, multiple  contracto r s a n d   vendors with  several archit ectural metho d s. “Th e   frag mentation of informatio n is  profou nd ” [4].  As previo usly  mentioned, this proje c t ha s bee n ca rrie d  out to find two differe nt semantic  repo sito rie s . As Kiryakov argu ed, O W L I M as an i n fe ren c e laye r a nd sto r ag e fo r Sesame  with  reliabl e  p e rsi s ten c e strate gy  and high  perfo rman ce  rea s oni ng ha s  the po we r  to  combin e  O W L  DLP, RDFS  and OWL Ho rst usi ng TRREE  en gine  [ 5 ].The follo wi ng  se ction  wi ll outline  O W LIM  in more d e ta il afterward   next part s   which  will  be  about the  ot her  rep o sito ry that is  call e d   allograph.     2.1. OWLIM:  A Pragmatic  Semantic Re pository  for OWL    OWLIM  with the perfo rma n ce of O W L  DLP re asoni ng is ba se d  on forward chainin g  of  entitlement ru les. Thi s  me a n s that the  g oal is  re acha ble amo ng  st arting from a v ailable fa cts or   data usi ng in feren c e rule s for extractin g  more  data  until that goal can  be a c hieved [6]. The  signifi can c e o f  OWLIM is it s scala b ility over million s  o f  statements.  In addition it  can p r o c e s s a  kno w le dge b a se of mo re  than 10 milli on explicit  st atements whi l e,  by  using forward ch aini ng  rea s oni ng, it has the pot ential to extend ha ndlin g  of statemen ts to arou nd  19 million. The  importa nt poi nt is th at a c cordin g to th e  size of   th e se mantic re po si tory,  the spe ed  of uplo adi ng  and  storin g i s  vari ed fro m  3000 to  180 00 state m ent s pe r  se con d  for a  small t o  maximal  si ze   repo sito ry. On the othe r h and, a s  note d , OWLI M  acts as an i n ference  st rategy , hence del etio n   pro c e s ses are not  chea p a nd it takes  a few mi nute s . Another fa ct t o  be  noted i s   that the amo unt   of diverse queries will be as sessed in m illiseconds [7].  Although  O W LIM  come s from the te rm of OWL In-Mem ory, a c cordi ng to  Kiryakov,  Ognyan ov a nd Ma nov “OWLIM i s  th e shor t nam e  of  the OWLMemSchem aRe p o s itory SAIL  (Storag e  an d  Inferen c e L a y er) for Se sa me, whi c h  su pport s  pa rtial  rea s oni ng o v er OWL DL P” .  As di scu ssed  by named  re sea r che r s  all  conte n t of  this repo sitory i s  p r e s erve d  and lo ade d from  the mai n  me mory, he nce i t  is  a  kind  of i n -mem or y re aso n ing   which  is capa ble  of  well -o rga n i z ed   query a n swe r ing a nd re covering,  sub s eq uently  it has  stron g  strategi es f o r ba ckup a nd  per sist e n cy .    The key featu r es of the  current rel e a s e o f  OWLIM ca n be sum m ari z ed as follo ws:     The mo st scalable sema n t ic repo sito ry in t he World ,  both in terms of the volume of RDF  data it can st ore an d the speed  with  whi c h it can lo ad  and infere nce.     Pure Java implementatio n, ensu r ing e a se of deploym ent and po rta b ility.      Compatible  with Sesam e  2,  whi c h  bri ngs interoperability ben efits  and support for all major   RDF  syntaxe s  and q uery l angu age s [8].    Special geom etrical quer y constructions and SPARQL ex tensions functions  [1].    High p e rfo r m ance retractio n  of stateme n ts and  thei r  inferen c e s -so  inferen c e m a teriali z ation  spe e d s  up ret r ieval, but without  delete p e rform a n c e d egra dation.      Powe rful  and expre ssive co nsi s ten c y/int egrity con s trai nt che cki ng  mech ani sm s.     RDF   Primin g,  based upo n activation sp readin g ,  allo ws effici ent dat a sel e ctio n a nd context- awa r e qu ery  answe ring fo r handlin g hug e datasets [9]  The limitatio ns of O W LI M are  rel a te d to its rea s oni ng  strate gy. In gene ral, the   expre ssivity  of the lan gua ge supp orte d  can not  b e  e x tended in  th e De scri ption  Logi c di re ction,  becau se the  sema ntics m u st be a b le  to be capture d  in (Horn) rules. Th e total materiali z a t ion  strategy h a s  dra w ba cks  when  chan ge s to the ex plicitly asse rted  stat ement s o c cur frequ ent ly.  For exp r e ssiv e  sem antics  and  certai n o n tologie s , the  numbe r of i m plicit state m ents  can  grow  quickly with the expe cted  degradatio n in perfo rman ce [10].    2.2. Allegro Graph    Allegro  Gra p h  is a  kin d  o f  databa se u s ed  as  a fra m ewo r k for  makin g  sema ntic web   appli c ation s . Data and m e ta-data  can b e  saved in it in the triples form and this tri p les  sea r ch (do   query )  is possible  among  different types of qu ery APIs such  as P r olog and SPARQL, along  with  the appli c atio n of RDFS ++ rea s o n ing  with its bu ilt-i n rea s on er. Allergo G r a ph i n clu d e s  su pp ort  for fede ratio n ,  so cial n e twork an alysi s   and  gruff [11] . Inter alia, Al legro  G r aph  i s   cha r a c teri zed   by being mo dern a nd a s  a databa se  with a  powerful, stable  grap hic fram e 20 and hi gh  Evaluation Warning : The document was created with Spire.PDF for Python.
IJEECS   ISSN:  2502-4 752     Chall enge s O v er T w o Sem antic Repo sit o rie s  - O W LI M and Allegro Grap h   (Pari a  Tajabo r)  196 efficien cy.  Compa r ed wit h   a rational  databa se,  a   grap hic data base can  ha ve any num b e r of  relation shi p s  for a n y save d sample.  Th ese  relation ships ap pea r i n  the fo rm  of  links  whi c h  take  the form of  a network o r  gra ph in  co mbinati on  wit h  ea ch oth e r. Combi ned  with di sk  ba sed  stora ge, Alle gro G r ap h efficiently make s use of  the memory. Thi s  cau s e s  a bet ter perfo rma n c e   and mainte n ance, while a t  the same time; billions o f  quads  can  be mea s u r ed . Among a very  high number of c lient applic ation programs ,  AllegroGraph  s u pports  SPARQL,  RDFS ++  and  prolo g  re ason ing [12].  Expressive a nd po we rful queryin g  an d  rea s oni ng is one of the  posit ive poi nts of this  approa ch. In  fact, Allegro  Grap h en able s  the mo st ex pan sive set of array s  for q uery an d a c cess  to information  in the RDF d a tastore. De scriptio n logi cs or O W L - DL  reasone rs  are  more  cap abl e  of man agin g   compl e x o n to logie s . Th ey  try to be   com p lete a n d  su ccessful i n   re spo ndin g  to   all  the que ries,  yet, on the other h and, wh en increa si n g  the numbe r  of triples to  millions; they  ac t  compl e tely different and a r e unp redi cta b le in te rms  of execution  time. Franze (201 0) beli e ves  that Allegro G r aph p r ovid es a very hi gh speed rea s on e r  and p r a c tica l RDFS ++.   Some Featu r es of Allegro Grap h are poi nted belo w :     Social Netwo r kin g  Analysi s  [11]    Native data types a nd Efficient rang e qu erie s [13]   Fede ration  [1 1]   Gruff  [14]  Reg a rdi ng the figure 1 ,  the stru cture  of  Allegro grap h ca n be better und ersto od.  Acco rdi ng to t he inferen c e  of Fran z, it sh ould  b e  menti oned th at “All egr o G raph provides a  RES T   proto c ol a r chi t ecture  whi c h  is essentially   a supe rset of the sesame  HTTP cli ent”.   Fran z  staff di rectly  cove rs ada pters fo r di fferent  lan guag es like  sesam e  java,  se same   Jen a , Python usin g the se same sig natu r e and Li sp.           Figure 1 .  Architecture of Allegro g r a ph [11]      3. Methodol og y   In this part th e ways that  has b een u s ed in  this p r o j ect to ben ch mark rep o sit o rie s  and  achi eve som e  rea s on able  results, are o u tlined a s  follows:    3.1. Information Sourcing   First  of all to  begin n ing t he an alysi s ,  I neede d h u ge am ount o f  ontologie s ,  and the  rea s on  wa s t o  put the s e  ontologi es to  the sel e cte d  repo sito rie s   for que rying  and a c cordin gly  ben chma rkin g. To this en d load s of ontologie s  we re  taken from t he main web  site of ontology  whi c h is (Wa t son.kmi.ope n). In additio n , a clas s of ontology fro m  my point  of view has  been  made a nd im ported it into  one of ontol o g ies, this  effort wa s don e to evaluate fa ster, ea sie r  a nd  for more accu racy an d co m p letene ss of queri e s.     3.2. Benchm arking and  Analy s is    The  aim  of th is p a rt i s  be n c hma r king  th e sele cted  se mantic re po si tories for  co mpari s on   betwe en thei r different  com pone nts a nd f i nally a  con c l u sio n  which  will be  ba sed  on the o b tain ed   Evaluation Warning : The document was created with Spire.PDF for Python.
                             ISSN: 25 02-4 752   IJEECS  Vol.  2, No. 1, April 2016 :  194 –  204   197 data. The s e repo sitorie s  a r e con s id era b l y  different  in the amou nt of their levels  and that mig h t  have influen ce on the final system s o n  deploy me n t  decisi on. For exampl e, load and q u e ry  response tim e s,  scalabilit y, s upported query la nguages, semantic expre ssivi ty or  reasoni ng   capability. Therefore, to  achiev e this goal  some qu eries were  provided  to use for  searchi ng  among t r iple s and findi ng t he rel e vant result s. Que r i e s a r e d e si gn ed from  simpl e  till compl e x for  better asse ssing in different situation s  and they   were tested  sep a rately in  each repo si tory  rega rdi ng to  their diffe rent  si ze s from  small to me di um si ze  onto l ogie s . It will  be te sting t w o  sema ntic re p o sitori es in t e rm s of their dat aset Loa d time, query result s and  query exe c uti o n   spe ed. By a d d ing va riou s  ontologi es in  variou s  si z e s into  s e lec t ed repos i tories ,  a total of four   different dataset si zes were creat ed to test reposit o ries in di fferent situations which  will  be   clarifie d more  in the prac ti cal part of proj ect.        4.   Finding   and   Analy s is   4.1. Benchm arking Fac t o r s   Some facto r s upon both re posito r ie s will  be briefly pre s ente d  in the Table 1.       Table 1. Feat ure s  of rep o si tories  Fac t ors   Allegrograph   BigO WLIM   Storage fo rm   Native-based   Memor y  and nati v e- based  Quer y La nguage   Support   SPARQ L , TWI N Q L ,  SeRQL a nd Prol og  SPARQL and  SeRQ L   Reasoner  Integration   Built-in, Jena,  Rac e rpro, S e s a me  Built-in, Sesame  RDF Up date   API  API  Reasoning tactic  Backw ard chaini ng  For w a r d chaining   Client part   PL/SQL, Java an d C  java  Platform maintained  Unix, Windo w s ,  Solaris and Mac  Unix, Windo w s ,  Solaris and Mac  RDF vie w  suppor t  Not definitive  No  Format of   Ser i alization   N-T r iples, RDF-X ML  and N3   N-T r iples, RDF- XML and N3       4.2. Test Des c ription    The next leve l of doing this benchma r k i s  testi ng th ese two ki nd of  sema ntic rep o sitori es  in term s of th eir d a taset L oad time,  qu ery results a n d  qu ery exe c ution  spee d.  The b a seline   test  is ru n on  sm all and m ediu m  size ontol o g ies. By addi ng vario u s  o n tologie s  in v a riou s  sizes i n to   sele cted  rep o s itorie s, a tot a l of four  different  data s et  sizes we re  created  to test  rep o sito rie s   in   different situ ations. In ot her  words, t h is te st ing is perfo rmed  with the follo wing va riatio n in  ontologi es-si z e con d ition s  (Table 2 ) .      Table 2. Onto logy sizes  cond itio ns   1  2  3  4  On tolo gies  or tr iples sizes   10000  50000  70000  100000       Furthe rmo r e  to better a s se ss th ese repo sitori e s  i n  different  si tuations, 5  d i fferent  queri e s  we re  cre a ted fro m  simple to  compl e x,  and  then they were te sted  se parately in e a ch   repo sito ry reg a rdin g to their different si ze s (Ta b le 3).       Table 3. Que r ies  Q u e r i es  Q1   Q2  Q3  Q4   Q5       Evaluation Warning : The document was created with Spire.PDF for Python.
IJEECS   ISSN:  2502-4 752     Chall enge s O v er T w o Sem antic Repo sit o rie s  - O W LI M and Allegro Grap h   (Pari a  Tajabo r)  198 Hen c e  given  these  4 ontol ogy si ze s an d 5 que rie s ,  a total of 20  test co ndition s have  been  pe rform ed o n  2  different  rep o sito ries  whi c h l e a d  to 40  resul t s that  will b e  illust rated  i n   following part s .    4.3. Data se t Load Timings   First  of all  l oadin g  a  pa rticular o n tolo gy  from  all f o ur data s et  sizes,  ba sed  on  two   selected repositori es has been done with t he help of SPARQL statements  whi c h is „ ‟ load  transpo rtation ’ ’ ,   can easily cal c ulate lo ad  time (Figure 2).           Figure 2. Tra n sp ortation o n tology loadi ng time      It can b e  cl ai med that Allo grap h h ad th e be st pe rformance in te rms of lo adin g  time and  they  are con s iste nt  an d scala b le agai n s t  in crea sing  data s et  size  and  BigO WLIM is the l o wer  repo sito ry be cau s e it perfo rms fo rward - chainin g  of facts and sto r e s   them explicitl y  [15].    4.4. Quer y  R esults a nd Execu tion Speed An aly s is     By performin g provide d  qu erie s, ope rati on of sea r chi n g and findi n g corre c t data  will be  activated an d  return ed ba ck to the bro w ser.    As mentio ne d befo r e to  evaluate b e tter, I mad e  a  cla s s from  my point of  view an d   importe d it into the ontolo g y of transpo rtation,  hen ce co ncept of all five queri e s are ba se d  on  t h is cla s s.      Quer y  1:    This i s  a rela tively simple  query  whi c h  wa s de sign e d  to find a dif f erent ki nd of  CityCar   as well as tho s e cl asse s which a r e di sjoi nted with it.     SELECT ?y ?x W H ERE    { ?x rdfs:subClassOf “CityCar ”  .    ?y owl:disjoint W i t h  “CityCar”   . }          Figure 3. Que r y 1 outcom e s       0 20 Data ‐ set01 D ata ‐ set02 D ata ‐ set03 D ata ‐ set04 Time(second) loading   time   Alle g r oG raph Bi gOW L IM 0 2000 Data ‐ set01 D ata ‐ set02 D ata ‐ set03 D ata ‐ set04 TIME(SECOND) DATA   SET   SIZES Bi g   Owlim Alle g r og raph Evaluation Warning : The document was created with Spire.PDF for Python.
                             ISSN: 25 02-4 752   IJEECS  Vol.  2, No. 1, April 2016 :  194 –  204   199 From the  Fig u re 3  ca n be  claime d that  this  que ry g enerally retu rns relatively quickly,  rega rdl e ss of  ontology  size. Both store s  were  co mp etitive up to dataset  04,  w i th sub-s e cond  res pon se t i m e s.       Table 4. Re sults of Que r y 1 in detail   Repos itor y   Data-set size   A n sw er   Correct a n s w er   Min ti me ( m sec )   Triple c o u n tin g   Allegrograph  10000   yes  yes  160  137  Big Ow lim  10000   yes  yes  73  107  Allegrograph  50000   yes  yes  253  67  Big Ow lim  50000   yes  yes  97  85  Allegrograph  70000   yes  yes  512  124  Big Ow lim  70000   yes  yes  214  97  Allegrograph  100000   yes  yes  1257   74  Big Ow lim  100000   yes  yes  116      114      From the tabl e 4 can b e  se en that all both store s  yield ed usable d a ta for this que r y.    Quer y  2:    This qu ery was de sig ned t o  find any rel e vant informa t ion about sp ecific  cu stom er, su ch a s   “pa r ia”.   SELECT ?x ?y ? z   ? w  ?p  ?R ?N  W H ERE   ? z   rdfs:subClass Of ?w   { “Paria ”  rdfs:sub ClassOf ?x  ?R rdfs:subClassOf ?N   ?x rdfs:subClassOf ?y   ?p rdfs:subClassOf ?R   ?y rdfs:subClassOf ? z   ?w  rdfs:subClassOf ?p .  }          Figure 4. Que r y 2 outcom e s       As it is sh own in the Figu re 4, this qu ery  generally re turns  relativel y  quickly, reg a rdle ss  of Ontolo gy size. It seem s  that AllegroG raph  did   b e t te r  on  th is  qu er y, w i th   r e s p on s e s   b e l ow   10 0   (m/se c ) acro ss the boa rd.  OWLIM  wa s clo s e be hind.       Table 5. Re sults of Que r y 2 in detail   Repos itor y   Data-set size   A n sw er   Correct a n s w er   Min ti me  (msec )  Triple  coun tin g   Allegrograph   10000   yes yes 31  88  Big  Ow lim  10000   yes yes 48  86  Allegrograph   50000   yes yes 46  107  Big  Ow lim  50000   yes yes 72  115  Allegrograph   70000   yes yes 69  115  Big  Ow lim  70000   yes yes 84  79  Allegrograph   100000   yes yes 78  132  Big  Ow lim  100000   yes yes 97  112      From the Ta b l e 5, it can be  seen that bot h  store s  yield ed usable d a ta for this que r y.      0 100 Data ‐ set01 D ata ‐ set02 D ata ‐ set03 D ata ‐ set04 TIME(SECOND) DATA   SET   SIZES Bi g   Owlim Alle g r og raph Evaluation Warning : The document was created with Spire.PDF for Python.
IJEECS   ISSN:  2502-4 752     Chall enge s O v er T w o Sem antic Repo sit o rie s  - O W LI M and Allegro Grap h   (Pari a  Tajabo r)  200 Quer y  3:    This query  which is relatively co mplex  attempts  to find different  k i nd s  o f   Sp or t Ca r  p l us   SU V  ca r .   After that, the query d e fine s tho s e  cars  whi c h a r e  City Car that u s e Fuel a nd re turns  ba ck th eir  types .  SELECT ? x  ? y   ? z  ?w  WHE R E  “FuelT y pe ” rdfs:s ubClassOf ?z  { ?x  rdfs:subClassOf “SUVCa r”  ? y  rdfs:subClass Of “Spo rtsCar> ”   ?z rdfs:subClassOf “Cit yCa r ”  ?w   rdfs:subClassOf “FuelT y pe” .  }          Figure 5. Que r y 3 outcom e s       Allegro g ra ph  had the  lo west respon se  times u p  to  dataset04,  with O W LIM  a clo s e  se con d . Ho wever, their re spon se at data s et04  wa s 5 times fa ster th an Allegrogra ph (Fig ure 5 ) .        Table 6. Re sults of Que r y 3 in details  Repos itor y   Data-set size   A n sw er   Correct a n s w er   Min ti me ( m sec )   Triple c o u n tin g   Allegrograph  10000   yes  yes  1495   90  Big Ow lim  10000   yes  yes  48  112  Allegrograph  50000   yes  yes  4532   107  Big Ow lim  50000   yes  yes  72  85  Allegrograph  70000   yes  yes  4376   115  Big Ow lim  70000   yes  yes  84  112  Allegrograph  100000   yes  yes  174321   105  Big Ow lim  100000   yes  yes  97  100      Quer y  4:    This q u e r y has b een p r ov ided to sho w   details of  sev e ral  cu stome r s, it deals  wit h  larg e   string s. T he  result  set g r ows lin early  with o n to logy  si ze. T h is q uery  gene rall y returns fairly  quickly at sm all ontology si ze s,  but slo w l y  at larger si zes.   SELECT ?y ?X ? z   ? A  ?B ?C  ? m  ? n  ?o ?T ? U  ?V W H ERE  ?y rdfs:subClassOf ?A   ?C rdfs:subClassOf ?o   {“T a ra: rdfs:subC lassOf  ?X   ?A rdfs:subClassOf ? m   “Zoh re ”   rdfs:subClassOf ? z   ?B rdfs:subClassOf ?n   “Paria ”  rdfs:subC lassOf ?y  ?m   rdfs:subClassOf ?T   ? z   rdfs:subClass Of ?C   ?n rdfs:subClassOf ?U   ?X rdfs:subClassOf ?B   ?o rdfs:subClassOf ?V .  }        Figure 6. Que r y 4 outcom e s   0 100000 200000 Data ‐ set01 D ata ‐ set02 D ata ‐ set03 D ata ‐ set04 Bi g   Owlim Alle g r og raph 0 50000 100000 Data ‐ set01 D ata ‐ set02 D ata ‐ set03 D ata ‐ set04 Bi g   Owlim Alle g r og raph Evaluation Warning : The document was created with Spire.PDF for Python.
                             ISSN: 25 02-4 752   IJEECS  Vol.  2, No. 1, April 2016 :  194 –  204   201 It can be  se e  that Allegro G rap h  ha d a  failure  at d a t aset04 t r iple s. And O w lim  yielded  usa b le data a t  all ontology sizes (Figu r e  6).       Table 7. Re sults of Que r y 4 in detail   Repos itor y   Data-set size   A n sw er   Correct a n s w er   Min ti me  (msec )  Triple  coun tin g   Allegrograph  10000   yes  Y e s   113  113  Big Ow lim  10000   yes  Y e s   116  110  Allegrograph  50000   yes  Y e s   583  95  Big Ow lim  50000   yes  Y e s   451  116  Allegrograph  70000   yes  Y e s   10001.5   330  Big Ow lim  70000   yes  Y e s   1948   115  Allegrograph   100000   No   -  -  -  Big Ow lim  100000   yes  yes  91841   113      OWLIM p e rf orme d the b e st on this q uery.  Alle g r oG r a ph  r u n n i ng  th e  s l ow est a t  th e   highe r o n tolo gy si ze s. Allegro G raph  h ad  some  of  t he fa ster tim e s  at Data se t01, 02 a n d  03;  however, it did not yield re sult s at data s et04 triple s (T able 7).     Quer y  5:  This qu ery is  desi gne d to test disjoi nts. Act ually this query trie s to find all classes whi c h   are  disj ointed  with Ve hicl e, as well a s  th at disj ointed   cla s s which h a s Be nz in it s su bcl a sse s   a nd  also tho s e cl asse s whi c h  have City Ca r in their  su b c la sses an d are di sjointe d  with BMW3. This  is the mo st complex que ry  in this proje c t.  SELECT ?x ?y ? z   ? v  ?w W H ERE   ?v rdfs:subClassOf ?x { ?y owl:disjointW i th “Vehicle ”   “Ben z ”   rdfs:subC lassOf ?v  ? z   rdfs:subClass Of “Vehicle ”   ?w rdfs:subClassOf “CityCa r ”  ?x owl:disjoint W i t h  “Vehicle ”   “BM W 3 ”  owl:disjoint W i th ?w . }  “CityCar”  rdfs:subClassOf  ? z             Figure 7. Que r y 5 outcom e s       This qu ery a s  is sh own in the figure 7 gene ra lly retu rns fairly qui ckly at small ontology  sizes, but sl owly at larg er  si ze s. And also Alleg r oGra ph did  not yield usable data a b o ve  dataset01 si zes.       Table 8. Re sults of Que r y 5 in detail   Repos itor y   Data-set size   A n sw er   Correct a n s w er   Min ti me  (msec )  Triple  coun tin g   Allegrograph  10000   yes  yes  4931   127  Big  Ow lim  10000   yes yes 98  120  Allegrograph   50000   No   -  -  -  Big Ow lim  50000   yes  yes  313  83  Allegrograph   70000   No   -  -  -  Big Ow lim  70000   yes  yes  983  62  Allegrograph   100000   No   -  -  -  Big Ow lim  100000   yes  yes  22509   113  0 20000 40000 Data ‐ set01 D ata ‐ set02 D ata ‐ set03 D ata ‐ set04 Bi g   Owlim Alle g r og raph Evaluation Warning : The document was created with Spire.PDF for Python.
IJEECS   ISSN:  2502-4 752     Chall enge s O v er T w o Sem antic Repo sit o rie s  - O W LI M and Allegro Grap h   (Pari a  Tajabo r)  202 Allegro G r a p h  only ran  at dataset0 1 , b u t had re sp o n se time s th at were mu ch highe r   than the su b-se con d  re spo n se s of OWLIM (Table 8 ) .     4.5. Summary   As ou r be nch m arking  over these  2 re p o sitori es  hav e finish ed, I woul d like to  highlight  some  we akn e sse s  and  st rength s  of e a ch tri p le  sto r e rega rdin g these in dicated re sult s a s  a   summ ary of this pa rt of pro j ect.   1.  AllegroGraph was gen erally slower than OWLIM, especially for larg er ontology  sizes. It  co uld not execute query 5 for larger ontologies.  This was probably the   hardest que ry for both systems. In addition it  performed better than  OWLIM o n   query 2.   2.  OWLIM did t he best on query 3. It ha d a close se cond to Alle groGraph o n  query 2. A  part of these  presented p o int are brief l y provided in Table 9 as a short summary.       Table 9. Sum m ary of Que r y Analysis   Quer y  Q1   Q2   Q3   Q4   Q5   Q6   A lle g r og ra ph        Dataset04   Dataset02-04   Big O w lim              Has correc t  da t a - do ne     Did n o t ru n or  ti me o u t     Incorrec t  da ta         5. Conclusio n s and Fu tur e  Work    Based  on the  evaluation ef fort, analysts  have  und erst ood that “the  curre n t state  of RDF  persiste n t sto r es, “tri ple sto r es”,  is not at a sufficie n tly  mature level to justify reco mmendi ng thei r  use in a p r od uction  system  being u s ed o n  a daily basi s ” [9], [16].    5.1. Ev aluation Summar y     If we want t o  summa rize  the evalu a tion b r iefl y, we should  say that it wa s  felt that  OWLIM  pe rfo r med  the  be st. OWLIM  wa s often  mu ch  better  at the  lower  ontolo g y si ze s, up   to   dataset02.  Ho wever, at  the  larg er ontology  si ze s, dat a s et 03 an d dat aset0 4 , OWLIM ‟ s  throug hput d r opp ed off dramati c ally in many ca ses. Thi s  assessment, wh ich was b a sed   prima r ily on p e rform a n c e a nd stability consi derat ion s , has been e v aluated in three mai n  levels.  These levels  were; Gene ra l, Functional  and Perfo r ma nce.      5.2. General  Ass essme n t    In the following Table 1 0 , we captured  some im porta nt factors tha t  we faced wi th them  durin g this p r oject an d pla y  a significa nt role in asse ssing e a ch system.      Table 10. Ge neral a s se ssment   Parameters   Feat ures   A lle g r og ra ph  Big O w lim  Usabili t y   Easy  t o  install  100%   25%   Easy  t o  develop   75%   75%   O v er all usability   75%  75%  Supp ort   Detecting defect s   15%   15%   Documentation  100%   100%   Overall Support   50%   80%   Licensi ng   ho w  w o rks   50%   50%       Generally, OWLIM got hi gh ma rks for usability a nd support.  And licensi ng of all   approa che s  i s  in the middl e level.  Evaluation Warning : The document was created with Spire.PDF for Python.
                             ISSN: 25 02-4 752   IJEECS  Vol.  2, No. 1, April 2016 :  194 –  204   203 Allegro G ra ph  got goo d ma rks for u s abili ty, and  overal l sup port  due  to the willin g ness of   the Fran z tea m  to engage  and wo rk on issue s  [11 ]. Howeve r, they  do not have a defect tracki ng  sy st em.     5.3. Functio n al Asse ssm ent    An overall qu alitative asse ssment of  perceptio ns i s  ca ptured in T abl e 11.      Table 11. Fu nction al asse ssment   Parameters  Feat ures   A l l e gro g rap h   Big  O w lim  Sy st e m   Architecture and  overall view  60%   95%   Data i m p o rt   batch loading  40%   90%   data formats sup ported   40%   90%   overall view  40%   90%   AP I   SPARQ L  90%  90%  overall view  50%   85%   Quer y i ng   overall view  50%   90%   Infren c y in g   overall view  -  90%   Intero perabi lit y   overall view  50%   50%   Oper a t io nal   overall view  -  40%       5.4. Perform a nce Asse ss ment   As 2  sele cte d  semanti c   repo sitorie s   were  analy z ed , it can  b e   claimed th at,  overall,  based o n  pe rforma nce an d usability, OWLIM  wa s  deeme d  the  best  rep o sit o rie s  (ba s ed  on     Table 11 ).     5.5. Future  Work   “Utilizi ng sem antic web   technolo g ies  in comm ercial a pplication s   re quire s co nfidence  by   the deci s io n make rs that the und erlying  semanti c   re p o sitori es  can  deliver the re quire d quality  o f   servi c e while managi ng the  overhea d of pro c e ssi ng th e metadata o f  potentially huge amo unt of  informatio n o r gani ze d in  complex taxon o mies” [1 7]. This stu d y e x plore s  the  a nalyzin g of t w o   sema ntic  rep o sitori es  and  my idea to  ben chma rkin g better a nd  more  accu rat e  for future a nd  further  work i s  expan ding  factors of asse ssm ent.  This in cludin g   addin g  more triples to billi on  one s, pe rformance im pa ct of   simult aneo us u s e r s an d tran sa ction-rel a te d p r o c e s ses,  modificatio n   test such a s  in se rtion,  updat e and  deletion ope ration s.  Fu rtherm o re, so me  addition al su pport s   can b e  provid ed t o  improve  th e que ry re sp onse times.  For exa m ple,  to   ensure  the  fresh n e s s of  d a ta, so me  efficient  upd ate s  o n   do cume nts  can  b e  o r gani ze d. Also  query optimi z ation tech niq ues  can h e lp  to improve th e query respo n se time.    Based  on  the s e m ention e d  point s I can  summ ari z e  m y  recomme nd ation for future work  in as follow:    deployme nt of more re posit orie s    developm ent of more ontol ogy    development of SPARQL syntax  in more c o mplex queries    more compl e x operation s  in repo sitori e s  to find out more accu rate about re spo n se time   su ch a s  upd a t e, deletion, modificatio n  and so on   And finally, in  future I  woul d like  to exa m ine  oth e r  s e mantic  re po sitory  a r chite c ture s to   explore m o re  about ea ch di fferentiation a s pe cts.       Referen ces   [1]    Seab orn e , And y . SPARQL Qu er y  L a n g u age f o r RDF . [Online] janu ar y   28,  200 8. [Cited: Jul y   28,  2011.] http:// w w w . w 3 .org/T R/ rd f-sparql-quer y /#grammar.   [2]   Bench m arkin g  over a Se ma nti c  Repos itory.  Yadav, Pran ju l a nd Sama la, Vin i th. 2010, IEEE , ICoAC,  pp. 51-5 9 .  [3]    Wiley ,  John and Sons . Ontology  Evolution.  S e mantic W eb T e chn o lo gi es.  onlin e : W ile y ,  2 006, pp. 5 1 - 70.   [4]   Desig n i ng a Se ma ntic Re posit ory.  Casan a ve,  Cor y . 2 007, M ode l Drive n  Sol u tions, pp. 1- 5.  [5]    T auberer, Josh ua. W hat is RD F  and  w hat is it  good for?  rdfabout.  [Onlin e] Janu ar y   20 08. [Cited:  August 05, 2 0 1 1 .] http:// w w w . r d fabo ut.com/in t ro/.  Evaluation Warning : The document was created with Spire.PDF for Python.