|
From: Bryan T. <br...@sy...> - 2010-05-01 13:41:05
|
Jürgen, You can host as many triple stores as you like in a single bigdata instance. Would that help? Each triple store has its own namespace. All of the indices for a given triple store are located within that namespace. For example, the default namespace is "kb". You could assign namespaces to each customer: "customer1" "customer2" etc. Triple stores created in this manner are completely disjoint, though they are in the same bigdata database instance. While this may not be relevant to your effort, we plan to add a feature to let you query across some or all triple (or quad) stores in a bigdata database using a protocol hint to identify the sources which you would like to consider. This is similar to the named/default graphs of SPARQL, but you are specifying the triple (or quad) store instances to be queried separately from the named/default graphs. This approach makes particular sense when you have many different customers who want their own quad stores so they can use their own interpretation of the context role in these quad stores, but you also have use cases for querying across data which those customers choose to "publish" as "shared" sources. Bryan > -----Original Message----- > From: Jürgen Jakobitsch [mailto:jak...@pu...] > Sent: Saturday, May 01, 2010 9:18 AM > To: Bryan Thompson > Cc: Mike Personick; big...@li... > Subject: Re: [Bigdata-developers] Inference and Quads > > hi thank you both for your answers. > > one usage pattern would be : > > we're developing a thesaurus management environment that > should be able to host many projects, where a project would > be a skos thesaurus of a certain knowledge domain. > > now we've two possibilities. > > either put every project in a different sail repository or > put all projects for one customer into a one single sail > repository and distinguish the projects by named graphs (quads). > > so first there's need for owl inference (for example for > narrowerTransitives, maybe just to check loops in the > thesaurus structure (a skos:narrower b skos:narrower c > skos:narrower a, for example) and there's need to get this > data not for all different thesauri but only for the > skos:concepts from one named graph (from one project) > > so the exact setup for us would be : > > put the skos:ontology in a namedgraph (a context) which > represents a project add skos:concepts (build the thesaurus) > to that namedgraph (context, project) infer > skos:narrowerTransitives for example from only this > namedgraph (context, project) > > for example : put a thesaurus about the semantic web into one > namedgraph (context, project) > put a thesaurus about the marketing department > of a company into another namedgraph (context, project) > > wkr www.turnguard.com/turnguard > > > ----- Original Message ----- > From: "Bryan Thompson" <br...@sy...> > To: "Mike Personick" <mi...@sy...>, "Jürgen Jakobitsch" > <jak...@pu...>, big...@li... > Sent: Saturday, May 1, 2010 11:24:57 AM > Subject: RE: [Bigdata-developers] Inference and Quads > > Jürgen, > > Let me add that we are interested in usage patterns for quads > with inference. For example, would you stores ontologies in > some context(s) and then use other contexts for managing > provenance but always desire entailments over all contexts? > > In that case, I believe that quads + inference may be > significantly simpler. > > Thanks, > Bryan > > > -----Original Message----- > > From: Mike Personick [mailto:mi...@sy...] > > Sent: Friday, April 30, 2010 3:41 PM > > To: Jürgen Jakobitsch; big...@li... > > Subject: Re: [Bigdata-developers] Inference and Quads > > > > Jurgen, > > > > The answer to inference with quads really lies in full query-time > > inference, which we do not yet support. We have sketchy > plans to work > > on query-time inference later this year after attending to several > > other priorities, most notably the high-availability > architecture for > > scale-out. > > > > The problem with quad inference is that supports for inferred > > statements can exist in different contexts, and it is not > known until > > query which contexts can be considered. Our model right now is to > > compute most inferences at load time. > > So if we compute inferences using supports from different > contexts, we > > would have to filter out query results based on whether they are > > supported by the specific contexts listed in the query. > > > > Thanks, > > Mike > > > > > > -----Original Message----- > > From: Jürgen Jakobitsch [mailto:jak...@pu...] > > Sent: Wednesday, April 28, 2010 1:55 AM > > To: big...@li... > > Subject: [Bigdata-developers] Inference and Quads > > > > hi, > > > > can you tell, when there will inference support with the quad store. > > > > we're currently starting development of the next version of out > > thesaurus management tool poolparty (poolparty.punkt.at) and are > > further evaluating triple stores. > > but we have a significant need for the combination of quads and > > inference. > > > > wkr turnguard.com/turnguard > > > > > > -- punkt. netServices > > ______________________________ Jürgen Jakobitsch Codeography > > > > Lerchenfelder Gürtel 43 Top 5/2 > > A - 1160 Wien > > Tel.: 01 / 897 41 22 - 29 > > Fax: 01 / 897 41 22 - 22 > > > > netServices http://www.punkt.at > > > > > > -------------------------------------------------------------- > > ---------------- > > _______________________________________________ Bigdata-developers > > mailing list Big...@li... > > https://lists.sourceforge.net/lists/listinfo/bigdata-developers > > > > -------------------------------------------------------------- > > ---------------- > > _______________________________________________ Bigdata-developers > > mailing list Big...@li... > > https://lists.sourceforge.net/lists/listinfo/bigdata-developers > > > > -- > punkt. netServices > ______________________________ > Jürgen Jakobitsch > Codeography > > Lerchenfelder Gürtel 43 Top 5/2 > A - 1160 Wien > Tel.: 01 / 897 41 22 - 29 > Fax: 01 / 897 41 22 - 22 > > netServices http://www.punkt.at > > |