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)
ihostart怎么样?ihostart是一家国外新商家,主要提供cPanel主机、KVM VPS、大硬盘存储VPS和独立服务器,数据中心位于罗马尼亚,官方明确说明无视DMCA,对版权内容较为宽松。有需要的可以关注一下。目前,iHostART给出了罗马尼亚vps的优惠信息,罗马尼亚VPS无视DMCA、抗投诉vps/2核4G内存/40GB SSD/100M端口月流量2TB,€20/年。点击直达:ih...
hostsailor怎么样?hostsailor成立多年,是一家罗马尼亚主机商家,机房就设在罗马尼亚,具说商家对内容管理的还是比较宽松的,商家提供虚拟主机、VPS及独立服务器,今天收到商家推送的八月优惠,针对所有的产品都有相应的优惠,商家的VPS产品分为KVM和OpenVZ两种架构,OVZ的比较便宜,有这方面需要的朋友可以看看。点击进入:hostsailor商家官方网站HostSailor优惠活动...
Sharktech(鲨鱼服务器商)我们还是比较懂的,有提供独立服务器和高防服务器,而且性价比都还算是不错,而且我们看到有一些主机商的服务器也是走这个商家渠道分销的。这不看到鲨鱼服务器商家洛杉矶独立服务器纷纷促销,不限制流量的独立服务器起步99美元,这个还未曾有过。第一、鲨鱼机房服务器方案洛杉矶机房,默认1Gbps带宽,不限流量,自带5个IPv4,免费60Gbps / 48Mpps DDoS防御。C...
graphsearch为你推荐
设备ituneswin7关闭445端口如何快速关闭445端口win10关闭445端口win10怎么关闭445的最新相关信息win7telnet怎样在win7下打开telnet 命令phpecho在php中 echo和print 有什么区别ms17-010win10蒙林北冬虫夏草酒·10年原浆1*6 500ml 176,176是一瓶的价格还是一箱的价格iphonewifi为什么我的苹果手机连不上wifi重庆电信宽带管家中国电信10000管家用着怎么样啊??联通iphone4iphone4想换联通的卡 是普通联通的卡都能开通3G么 还是得换联通3G卡 联通都有什么套餐 我是北京的icloudiphone苹果6显示已停用请连接itunes什么意思
日本私人vps 赵容 yardvps diahosting edis 512av 英文简历模板word 名片模板psd http500内部服务器错误 qq数据库下载 骨干网络 上海域名 怎么测试下载速度 东莞数据中心 空间技术网 服务器硬件防火墙 512mb 美国盐湖城 游戏服务器出租 中国linux 更多