annotategraphsearch

K.
Abereretal.
(Eds.
):ISWC/ASWC2007,LNCS4825,pp.
792–801,2007.
Springer-VerlagBerlinHeidelberg2007Spatially-AugmentedKnowledgebaseDaveKolasandTroySelfBBNTechnologies1300N.
17thSt.
,Suite400,Arlington,VA22209{dkolas,tself}@bbn.
comAbstract.
Asanincreasingnumberofapplicationsonthewebcontainsomeelementsofspatialdata,thereisaneedtoefficientlyintegrateSemanticWebtechnologiesandspatialdataprocessing.
Thispaperdescribesaprototypesys-temforstoringspatialdataandSemanticWebdatatogetherinaSPatially-AUgmentedKnowledgebase(SPAUK)withoutsacrificingqueryefficiency.
Thegoalsaremotivatedthroughuseseveralusecases.
Theprototype'sdesignandarchitecturearedescribed,andresultingperformanceimprovementsarediscussed.
1IntroductionWiththeadventofsocialnetworkingsites,wikis,andotherwebenvironmentsthatfallundertheumbrellaofwebcollaborationtechnologies,exposingthedatabehindwebsitesinmachine-readableformatsisbecomingevermorepopular.
MuchoftheinformationlinkedandsharedacrosstheWebbecomesmoreusefulwhencombinedwithitsspatialcontext.
Crimestatistics,real-estateinformation,andrestaurantre-viewsareexamplesofinformationthatismoreusefulwhenconsumedfromaspatialperspective.
UsingWeb2.
0techniques,websitescommonlyreferredtoas"mash-up"sitesareabletodisplayinformationspatially.
Forexample,onesitemayoverlaycrimestatisticsonamapusingGoogleMaps1whileanothersitedisplayshousesforsaleonGoogleMaps.
Inbothcases,thecombinationofdataandcapabilitiesisprede-finedbythemash-upsiteandisonlyusedfordisplaypurposes.
SemanticWebtechnologies,suchastheResourceDescriptionFramework(RDF)andtheSPARQLProtocolandRDFQueryLanguage(SPARQL)arebeginningtoeliminatethislimitation.
ThegraphstructureofRDFalongwiththegraphqueryca-pabilitiesofSPARQLmakethemidealcandidatesforrepresentingandsearchingtheever-changing,interlinked,flexibledataoftheWeb,whichisnoteasilydoneusingatraditionalrelationaldatabase[1].
RDFdatabases,sometimescalledtriplestores,offersignificantadvantagesovertra-ditionalstructureddatabasesforSemanticWebdata[2],butarenotoptimizedforspatialinformationsuchasgeographiccoordinates.
Inthispaper,wedescribeaSpa-tiallyAUgmentedKnowledgebase(SPAUK)thatprovidesthehigh-performancegraphquerycapabilitiesneededforsearchingwebsofdata,withoutsacrificingthespatialindexingandprocessingcapabilitiesnecessaryforperformingsearches1http://maps.
google.
comSpatially-AugmentedKnowledgebase793involvingspatialextentsandoperators.
Herewedescribeourmotivationsandexam-pleusecasesfortheaugmentedknowledgebaseaswellasthedesignandimplemen-tationresults.
Finally,wediscussthestatusoftheprototypeandfuturedirection.
2MotivationWhileRDFandmoderntriplestoresareefficientatstoringandqueryingdatalinkedacrossmultiplesourcesofinformation,theyarepoorperformerswhenitcomestospatialprocessing.
Thecurrentstandardforstoringspatialdatagenerallyinvolvesus-inganobject-relationaldatabaseaugmentedwithspatialcapabilities,suchasOracleSpatial.
Whilethisapproachhasproveneffectivewithinapredominantlyspatialenvi-ronment,theobject-relationalmodellackstheflexibilityofRDFandtriple-storesthatmakethemattractiveforsearchinglinkeddataacrossmultiplesources.
ThegoalofSPAUKhereistoprovideefficientstorageandqueryofspatialdatawithoutsacrific-ingtheflexibilityandgraphsearchabilityofRDFandtriplestores.
2.
1UseCasesQueryMash-upsOnlinecommunities,specificallysocialnetworkingsites,haveledtoasurgeinavail-abledataaboutrelationshipsbetweenpeople.
Inmanycases,apersonwillownanidentityonseveralsitesandprovidelocationinformationaboutwheretheyliveorwork.
ThegraphstructureofRDFmakesitnaturalforrepresentingtheinformationdistributedacrossthesesites.
CombiningthegraphquerycapabilitiesenabledbyRDFwithefficientspatialprocessingallowsustosearchforpeoplebasedonprofiledatafrommultipleonlineidentities,filteredwithinaparticularspatialboundary.
Asade-veloper,Imaybeorganizingaworkinggroupandwishtofindotherdevelopersnearmewithsimilarinterests.
Agraphsearchsupplementedwithspatialinformational-lowsmetosearchforallemployeesofcompanieslocatedwithin2milesofmycom-panywhoaredevelopersonSemWebCentral2andhavelistedtheiremployersontheirFacebook3account.
Givenlocationinformationaboutlocalcoffeeshops,Icanalsosearchforacoffeeshopcentrallylocatedbetweenuswherewecanmeet.
Searchesliketheserequiretheabilitytolinkandsearchinformationfrommultipleonlinesourceswhileboundingthequeryandresultswithinspatialconstraints.
Withoutspa-tialquerytechniques,graphquerieslikethesemaywastetimeprocessingallcoffeeshops,allSemWebCentralusers,orallFacebookusersbeforetestingthelocationin-formationtodetermineiftheymatchthequery.
SpatialAnnotationWebsitesexistthatallowuserstosubmitreviewsaboutallkindsoftopics,includingmovies,books,andrestaurants.
Inthelattercase,thegeospatialinformationisimpor-tantwhenitistimetosearchreviews.
Auserwillmostlikelyonlybeinterestedin|reviewsofrestaurantswithinaparticularboundaryornearaparticularevent.
2http://www.
semwebcentral.
org3http://www.
facebook.
com794D.
KolasandT.
SelfAknowledgebasethatallowsefficientstorageandsearchofinterlinkeddataalongwithgeospatialdataenablesanapplicationthatallowsuserstoannotaterestaurantsonamap,reviewtherestaurant,andprovidedetailsabouttherestaurantbylinkingtootherdataorreviewersontheWeb.
Suchanapplicationwouldallowasearchforgoodrestaurantsnearaparticularconference.
2.
2QueryTypesInordertosupportthecombinationofsemanticandspatialdata,onemustconsiderseveraldifferenttypesofqueries.
Thework[3]ofEgenhoferonspatialquerylan-guagesbasedonSQLdefinedthreetypesofqueries:QueriesaboutspatialpropertiesQueriesaboutnon-spatialpropertiesQueriesaboutbothspatialandnon-spatialpropertiesApplyingthesestraightforwardconceptstoaSemanticWebsystemyieldsthreeanalogousqueryclasses:QueriesaboutspatialpropertiesQueriesaboutontologicalpropertiesQueriesaboutbothspatialandontologicalpropertiesAmongthespatialpropertiesthatcanbequeriedover,severaltypesofspatialquerieshavebeenidentified:QueriesaboutthespatialpropertiesofanindividualQueriesthatrelateindividualstoaknownlocation(pointandrangequeries)Queriesthatrelateindividualstooneanother(spatialjoin,nearestneighborqueries)QueriesthatspatiallyaggregateindividualsWewillnowexploreeachofthesetypesofspatialqueriesindividually,asappliedtoastoragemechanismthatalsosupportsontologicaldata.
Thesimplesttypeofspatialqueriesisqueriesforthelocationofaknownobject:"WhereisthelocationofJimmy'sPizzaParlor"Thistypeofqueryisessen-tiallystraightforwarddataretrieval,anddoesnotnecessarilyrequireanyspecializedspatialprocessing.
Assuch,asemanticsystemcouldsupportthesequerieswithoutmodification.
Thesecondtypeofspatialqueriesrelatesindividualstoaknownlocation.
Thislocationcouldbeanotherspecificobjectintheknowledgebase,i.
e.
:"Whichgassta-tionsarewithin1mileofJimmy'sPizzaParlor"oranabsolutelocation,i.
e.
:"Whichgasstationsarewithin1mileof38°N,77°W".
Naturally,thesequeriesmustbecrossedwithontologicalinferenceaswell:"Whichrestaurantsarewithin1mileofGus'sGas"where'restaurants'mustincludeentitiesdefinednotspecificallyasrestaurants,butthosedefinedasPizzaParlors,SubShops,etc.
,also.
Thethirdtypeofspatialqueriesrelatesindividualstooneanother.
Thisclassincludesbothspatialjoinsandnearestneighborqueries.
Forexample,"WherecanIgotobuybananas,milk,andadrillwithina2mileradius"involvesnotonlytheSpatially-AugmentedKnowledgebase795spatialjoinbetweentheindividualplaces,butalsotheontologicalinferenceofthetypesofstoresthatselltheitemsinquestion.
Ourspatialsemanticknowledgebasemustbeabletosupportallofthesetypesofqueries,andcombinationsthereof,efficiently.
3RelatedWorkSignificantresearchhasgoneintocreatingvarioustypesofefficientspatialindexstructures.
Theseindexstructuresaregenerallyusedasasupplementalindextoanobject-relationaldatabase.
Addingthesupplementalindicesallowstheobject-relationaldatabasestosignificantlyincreasetheirperformancewithrespecttospatialqueries.
Theindicesareattachedtoacolumnorcolumnsdefinedasaspatialdatatype.
Awidevarietyofusefulspatialindexstructuresexist,eachwithitsownpositiveandnegativecharacteristics.
Mostfallwithinasmallnumberofmajorfamilies,how-ever.
TheseareR-trees[4],quadtrees[5],andgridfiles[6].
Sincewewillnotbeat-temptingtoenhancetheseindexstructuresinanyway,ourdiscussioninthisareawillfocusonwhichisappropriatetoattachtoasemanticknowledgebase.
4DesignTheprimarygoalofSPAUKistoprovideefficientspatialprocessingforspatialse-manticsystems.
Wecanleveragethesignificantworkthathasgoneintooptimizingdatabasesystemsforspatialdataprocessing.
Thesesystemstypicallyemployasup-plementaryspatialindextoprovideefficientspatialqueries.
Assuch,wechosetodesignSPAUKasasemanticknowledgebasecapableofsupportingsupplementaryspatial(andother)indices.
Asecondarygoalwastodesignasystemsuchthattheadditionofspatialprocess-ingtothesystemisastransparentaspossibletotheuser.
Thismeansthatfromacli-ent'spointofview,allofthedata,boththesemanticdataandthespatialdata,isstillpresentedasagraph.
Todothis,theknowledgebasepresentsitselfasastandardSPARQLendpoint.
ThisallowsanyclientscapableofinterfacingviatheSPARQLprotocoltoutilizeSPAUK.
Thus,thedesignmustpresentoneconceptualgraphtoitsclients,andqueriesoverthisgraphmustbedividedappropriatelyintosub-querieswhichcanbeansweredbythevariouspartsoftheknowledgebase.
Spatialpartsofthequery,includinglocationsandspatialrelationships,mustbesenttothespatialindexandqueryprocessor.
Non-spatialcomponentsofthequerymustbesenttotheunderlyingtriplestore.
Resultsmustbecombinedfromthetwopartstoformacoherentanswer.
Moreover,datawhichisinsertedmustfinditswayintotheappropriatepartsoftheknowledgebase.
4.
1InterfaceAsnotedbefore,SPAUK'sexternalinterfaceutilizestheSPARQLprotocolforqueryaccess.
However,mappingqueriesthatincludespatialinstancesandrelationshipsto796D.
KolasandT.
SelfSPARQLisnotnecessarilystraightforward.
TherearemanypossiblewaysthatonecoulduseSPARQLforspatialdata,andtheidealwayhasyetbeenattained[7].
Forourprototype,westayedwithintheboundsofSPARQLasitiscurrentlydefined.
Whilethisdidnotnecessarilyprovidethecleanestpossiblespatial-semanticqueryin-terface,itdidallowustoutilizeothersemanticwebsoftwarewithoutmodification.
Inordertodothis,weneededtodefineasetofclassesandpropertiestorepresentobjects,attributes,andrelationshipsthattheknowledgebasecouldunderstand.
Nu-merouscandidaterepresentationsalreadyexist.
GeoRSSisagoodchoiceforrepre-sentingspatialextentsbecauseitissimple,italreadyhasanRDFsyntax,anditisbasedontheOpenGeospatialConsortium'sstandardforrepresentingspatialextents,GeographyMarkupLanguage(GML)[8].
Usinganotherrepresentation,suchasthespatialportionsofacommonlyusedupperontology,couldhaveworkedjustaswell.
Forthespatialrelationships,wedecidedtostartwithasetofqualitativetopologicalrelationshipsbasedontheRegionConnectionCalculus[9].
First,welookatanex-ampleofaGasStationexpressedusingtheseconcepts:[]agas:GasStation;gas:name"Gus'sGas";gas:brandgas:Exxon;gas:numberOfPumps"8";georss:where[agml:Point;gml:pos"38-77"].
].
Thefollowingisanexampleofthequery,"Whichgasstationsarewithin1mileof38°N,77°W"encodedasdescribed.
SELECTxWHERE{xagas:GasStation;georss:wherey.
yrcc:part[agml:Buffer;gml:radius"1";gml:bufferGeometry[agml:Point;gml:pos"38-77"].
].
}Thisprovidesaninterfaceforquerying,butdoesnotallowforinsertionordeletionoftriples.
SincethisisanecessaryforoursystemandisnotyetpartoftheSPARQLspecification,weaddedHTTPinterfacemethodsforbothinsertionanddeletion.
ThesemethodsmerelyrequireasetofRDFtriplesbeingpostedtotheappropriateURLs.
TogetherwiththeSPARQLmethods,thesemethodsdefinetheentiretyoftheexternalinterfaceofSPAUK.
Spatially-AugmentedKnowledgebase7974.
2ArchitectureInordertofacilitateinteroperabilityandleverageexistingsemanticwebsoftware,thearchitectureofSPAUKisbasedontheJenaSemanticWebFramework4andJoseki5.
Utilizingthesetoolsallowedustofocusonthecorequery-splittingandspatialcom-ponentsofSPAUK.
ThebasicideaofthearchitectureistohaveaspecializedSPAUKGraphimplemen-tationofthecom.
hp.
hpl.
jena.
graph.
GraphJavainterfacethatdealswiththesplittingandcombiningoftheinformationthatgoesinandoutoftheknowledgebase.
SPAUKGraphdealsdirectlywithsomesetofIndexProcessors,whichrepresenttheinterfacetothedatastoredin1ormoresupplementalindices.
WeaddresshowtheGraphhandlesqueriesandinsertionbelow.
Fig.
1.
ClassdiagramfortheSPAUKGraphanditsrelationtotheIndexProcessors4.
2.
1DataInsertionTheunderlyingtriplestorecontinuestobethemastercopyofallinformationinSPAUK.
Alldatainsertedisintheformofstatements,whichareinserteddirectlyintotheunderlyingtriplestore.
Thereisanimportantdichotomybetweenthestatementsinthetriplestoreandthecontentsofthesupplementalindices.
Whilethedatainthetirplestoreisagraph,thedatathatgoesinthesupplementalindicesaresetsofdiscreteobjects,i.
e.
spatialex-tents.
Thismakesknowingwhentoinsertanobjectintothesupplementalindexsomewhattricky.
Theinsertioninterfaceseesthestatementsbeingaddedoneatatime,andmustcombinesetsofthemtoformobjectstobeinserted.
WeaccomplishedthisthroughtheuseofJena'sInfGraph.
Foreachtypeofobjectthatthesystemmust4http://jena.
sourceforge.
net/5http://www.
joseki.
org/798D.
KolasandT.
Selfwatchfor,aruleisaddedtoanInfGraphlayerabovetheunderlyingtriplestore.
TheheadoftheruleisafunctionthatconnectstotheappropriateIndexProcessortoaddanobjecttotheindex.
Therulewillnotfireuntilallrequiredcomponentsareavailable.
Thisrule,forexample,addspointstothespatialindexprocessorwhentheyareinserted:[point:(xrdf:typegml:Point)(xgml:pospos)->point(x,pos)]Thisschemeallowsfortheinsertionofobjectsintotheindiceswithoutconcerninguswiththetransactionalityofthedatastore.
Infact,ifpartofageometrydefinitionisinsertedatsomepoint,andthenmuchlatertherestofthedefinitionisinserted,thegeometrywillbeindexedsuccessfullyatthelaterpoint.
However,itdoesnotaccountforupdatesordeletionsofstatementscorrespondingtoindexedobjects.
Assuch,in-dexedobjectsaretreatedasimmutablewithinthesystem.
Ifthelocationofarestau-rantchanges,ratherthanchangingthepropertiesofthelocationobjecttowhichtherestaurantisattached,therestaurantmustbeseveredfromthelocationandanewlo-cationcreated.
4.
2.
2QueryingQueryingthecombineddatastorageisthemostcomplicatedpartofthesystem.
Theappropriatepartsofthequerymustbepartitionedamongtheunderlyingtriplestoreandthesupplementalindices,dependinguponwhichpartsarecapableofmosteffi-cientlyansweringeachpieceofthequery.
WhentheSPAUKGraphreceivesthequery,itfirstsplitsthequerybasedonthenamespacesoftheassociatedwiththeattachedIndexProcessors.
Foreachtriple,thenamespaceofthepredicateortheClass(forrdf:typestatements)ismatchedagainstthenamespacesassociatedwiththeIndexProcessors.
Ifanamespaceisnotassoci-ateedwithanIndexProcessor,itdefaultstoassociationwiththeunderlyingtriplestore.
Forinstance,inthefollowingquery,theportionthatmustbeprocessedbythespatialindexprocessorhasbeenitalicized:SELECTxWHERE{xagas:GasStation;georss:wherey.
yrcc:part[agml:Buffer;gml:radius"1";gml:bufferGeometry[agml:Point;gml:pos"38-77"].
].
}Spatially-AugmentedKnowledgebase799Unfortunately,thisassignsartificialmeaningtothenamespacesofwhichthequeryprocessorisaware.
Thiscouldleadtoerrorsinprocessingiftheusersattemptedtoextendthespatialontologiesinawaythatthesystemdidnotunderstand.
Sincenobetterwaytodividethestatementsatthequerylevelhasyetcometolight,thisisthemethodthattheSPAUKprototypeuses.
Oncethequeryhasbeendividedintoappropriateparts,theSPAUKGraphmustmakeabest-effortattempttodeterminewhichpartofthequeryisthemostselective.
Sinceitdoesnothaveanyinformationabouttheselectivityofthequerypartsdirectly,itmustasktheunderlyingtriplestoreandtheIndexProcessorstoapproximatethese-lectivityoftheirpartsofthequeryasanestimatednumberofresults.
Developinganappropriatecostmodelforthisisanareaoffuturework.
Inthecurrentimplementa-tion,ifthespatialqueryprocessorreceivesaqueryforobjectswithinaspecifiedarea,itreturnsthehighestpossibleselectivityandthusischosenfirst.
Inallothercases,thesystemdefaultstoallowingthetriplestoretobindfirst.
Otherpossibilitiesincludeattemptingtoexecutethedifferentpartsinparallel,howeverthiswasbeyondthescopeofourprototype.
AninitialsubqueryischosenandthenexecutedbyeithertheunderlyingtriplestoreoranIndexProcessorasappropriate.
Thebindingsfromthissubqueryarethenap-pliedtotheothersubqueriesastheyareexecuted.
Sincethelinkageobjectsbetweenthespatialandnon-spatialportionsareboundatthispoint,itisexpectedthatthese-lectivityoftheremainingboundsubqueriesshouldbeextremelyhigh.
ThoughSPAUKsupportsSPARQL,theSPARQLsupportisprovidedexclusivelybytheARQcomponentofJena.
Thusoursystemdealsonlywithqueriesintheformofsimplegraphpatterns.
Thisdrasticallyreducestheamountofqueryprocessingworkthatneedstobedone;however,therearecaseswherethisdesigncreatesSPARQLqueriesthatcouldnotbeproperlyoptimizedusingtheindex.
ThiscouldhappenifthedefinitionoftherangeinarangequeryweresplitoveranOPTIONALclause.
Sincethesecasesareprimarilyconnectedtopoorqueryconstruction,wecur-rentlyignoretheminthedesign.
4.
3IndicesThespatialindexusedintheprototypewasasimplein-memorygridfile.
Thisisnotaparticularlysophisticatedspatialindex;however,thesoftwarewasdesignedsuchthatsubstitutinganotherindexingmechanismshouldbestraightforward.
Ideally,wewouldliketoaddeitheraquadtreeorR-treeindexingmechanismtoSPAUK.
Havingbothavailabletospatialapplicationsisideal,sincebothhavestrengthsandweaknessesdependingonthedistributionofthedatabeingstored.
Par-ticularly,quadtreesfunctionbetterthanR-treeswhendataismoreevenlyspatiallydistributed,andR-treesfunctionbetterwhendataismorespatiallyclustered.
Sincethereareapplicationswhichcouldpotentiallymakeuseofbothtypesofindices,theoptionofbothshouldexist.
ThisisanalogoustothespatialindexsupportprovidedincommonspatialrelationaldatabasessuchasOracleSpatial10g.
5ResultsTheSPAUKsystemwassuccessfullyimplementedforasubsetofthedesiredprob-lem.
Processingwasimplementedfortwomajortypesofspatialgeometries:Points800D.
KolasandT.
SelfandPolygonsdefinedbyanexteriorlinearring.
Ruleswerecreatedtodetectthesegeometriesandinsertthemintotheindex.
Twospatialrelationshipswereimple-mentedoverthesepolygons,connectedandpart.
Theseallowedustosufficientlytestthequerysplittingmechanism.
Unfortunately,withoutthecreationofspatialsemanticbenchmarks,wedonotyethaveawaytoempiricallytesttheperformanceoftheSPAUKsystem.
However,considerationofthepriorartintheobject-relationaldatabaserealmandacarefullookattheindexstructuresdemonstratesthatthetechniqueissuperior.
Considerattemptingtobuildasystemforspatialsemanticdatawithoutanyspatialindexing.
Aqueryforallrestaurantsthatareina2mileradiusfromagivenpointwouldclearlybeO(n)inthenumberofrestaurants,sincethesystemwouldhavetocompareeachandeveryrestaurant'slocationtothespatialbufferarea.
However,ifaquadtreewasusedforspatialindexing,wewouldexpectthetimetofindobjectsintheradiustobelogarithmic.
6ConclusionWhilewehavenotyetdoneformalanalysisoftheperformanceimprovementcausedbyusingasupplementalspatialindex,examplesofthetechniqueintheobject-relationaldatabaseworld,simpleanalysisofthealgorithmsinvolved,andpreliminaryusageoftheSPAUKsystemhaveshownthattheapproachisindeedvalid.
AttachingasemanticGISclienttotheSPAUKsystemprovidesresponsivespatialsemanticquerycapability.
Webelievethatthistypeofsystemenablesanewclassofsemanticapplicationswhosefullpotentialcannotyetbeconceived.
WaldoTobler's"firstlawofgeography"states,"Everythingisrelatedtoeverythingelse,butnearthingsaremorerelatedthandistantthings.
"[10]SinceagoaloftheSemanticWebistomaxi-mizethemeaningofrelationships,spatialinformationprocessingcannotbeignored.
7FutureWorkThefirstmajorpieceoffutureworkfortheSPAUKsystemwillbetofullyimplementtheGeoRSSgeometrytypesandtheRCC8spatialrelations.
Thiswillprovideafullyusablesystemforexperimentationwithspatialsemanticdatastorage,andhopefullyprovideotherswithamethodofbuildingspatialsemanticapplicationswhenitsoonbecomesopensource.
Thesecondpieceoffutureworkinvolvessignificantlymoreformalperformancetesting.
However,thiswillrequireseveralotheradvancements.
First,abenchmarkforspatialsemanticdatamustbecreated.
ThiscouldverywellbeanenhancementoftheLehighUniversityBenchmark(LUBM)[11].
Secondly,SPAUKwouldneedtobeattachedtoamorerobustspatialindex,suchasapersistentR-tree.
Withthesemodificationsinplace,SPAUKwillbeformallycomparedtoasemanticspatialsys-teminwhichspatialcalculationsareperformedonlyasfunctioncallsinrules.
Finally,extendingtheSPAUKimplementationwithatemporalindexorotherindi-cesisverydesirable.
Thearchitectureisbuiltnotjustforonesupplementalindex,butformany;hopefullyitcanprovidebenefitforawidevarietyofapplicationareas.
Spatially-AugmentedKnowledgebase801Acknowledgements.
WewishtothankMikeDeanandBBNTechnologiesfortheirsupportofthiseffortandhelpfulcommentsonthepaper.
References1.
ConnectedServicesFramework3.
0DevelopersGuide.
Microsoft(2006)2.
Lassila,O.
,Hendler,J.
:EmbracingWeb3.
IEEE11,90–93(2007)3.
Egenhofer,M.
:SpatialSQL:AQueryandPresentationLanguage.
IEEETransactionsonKnowledgeandDataEngineering6,86–95(1994)4.
Guttman,A.
:R-trees:adynamicindexstructureforspatialsearching.
ACMPress,NewYork(1984)5.
Finkel,R.
A.
,Bentley,J.
L.
:Quadtreesadatastructureforretrievaloncompositekeys,pp.
1–9.
Springer,Heidelberg(1974)6.
Nievergelt,J.
,Hinterberger,H.
,Sevcik,K.
C.
:TheGridFile:AnAdaptable,SymmetricMultikeyFileStructure,vol.
9,pp.
38–71.
ACMPress,NewYork(1984)7.
Kolas,D.
:SupportingSpatialSemanticswithSPARQL(2007)8.
ISO/TC211/WG4/PT19136Geographicinformation-GeographyMarkupLanguage(GML)(2004)9.
Cohn,A.
G.
,Bennett,B.
,Gooday,J.
,Goss,N.
M.
:QualitativeSpatialRepresentationandReasoningwiththeRegionConnectionCalculus.
GeoInformatica1,275–316(1997)10.
Tobler,W.
R.
:AComputerMovieSimulatingUrbanGrowthintheDetroitRegion.
JSTOR46,234–240(1970)11.
Guo,Y.
,Pan,Z.
,Heflin,J.
:LUBM:ABenchmarkforOWLKnowledgeBaseSystems.
JournalofWebSemantics3,158–182(2005)