> Those sure are good reasons for using named graphs. But what about using > different datasets too?
Consider that you may not be seeing such reasons because it may not actually be as good an idea. Here's another reason to prefer graphs: There is a standard management HTTP API for named graphs: SPARQL Graph Store. There is no equivalent for datasets, so each product rolls its own. That's not good for flexibility if you have to move products. As for performance, that will depend radically on the implementation. Jena TIM, for example, using hashing for its indexes, so the difference between having a lot of quads in a dataset and a few isn't likely to be that much. Other impls will vary. Are you sure that performance is going to be improved by separating out datasets? (I.e. is that the measured bottleneck?) Are you now having problems with queries accidentally querying data they shouldn't see, and can your queries be rewritten to fix that (which might also improve performance)? (Jena has a permissions framework that can secure information down to the individual triple.) ajs6f > On Mar 21, 2018, at 6:35 AM, Mikael Pesonen <mikael.peso...@lingsoft.fi> > wrote: > > > Those sure are good reasons for using named graphs. But what about using > different datasets too? > > btw, I couldn't find info on how to run many datasets with Fuseki. is it just > one dataset per fuseki process? -loc parameter for fuseki-server.jar? > > Br > > On 20.3.2018 14:22, Martynas Jusevičius wrote: >> Provenance. With named graphs, it's easier to track where data came from: >> who imported it, when etc. >> You can also have meta-graphs about other graphs. >> >> Also editing and updating data. You can load named graph contents (of >> smallish size) in an editor, make changes and then store a new version in >> the same graph. You probably would not want to do this with a large default >> graph. >> >> On Tue, Mar 20, 2018 at 1:16 PM, Mikael Pesonen <mikael.peso...@lingsoft.fi> >> wrote: >> >>> Hi, >>> >>> I'm using Fuseki GSP, and so far have put all data into one default >>> dataset and using graphs to split it. >>> >>> If I'm right there would be benefits using more than one dataset >>> - better performance - each query is done inside a dataset so less data = >>> faster query >>> - protection of data - can't "accidentaly" query data from other datasets >>> Downsides: >>> - combining data from various datasets is heavier task >>> >>> Is this correct? Any other things that should be considered? >>> >>> Thank you >>> >>> -- >>> Lingsoft - 30 years of Leading Language Management >>> >>> www.lingsoft.fi >>> >>> Speech Applications - Language Management - Translation - Reader's and >>> Writer's Tools - Text Tools - E-books and M-books >>> >>> Mikael Pesonen >>> System Engineer >>> >>> e-mail: mikael.peso...@lingsoft.fi >>> Tel. +358 2 279 3300 >>> >>> Time zone: GMT+2 >>> >>> Helsinki Office >>> Eteläranta 10 >>> <https://maps.google.com/?q=Etel%C3%A4ranta+10&entry=gmail&source=g> >>> FI-00130 Helsinki >>> FINLAND >>> >>> Turku Office >>> Kauppiaskatu 5 A >>> <https://maps.google.com/?q=Kauppiaskatu+5+A&entry=gmail&source=g> >>> FI-20100 Turku >>> FINLAND >>> >>> > > -- > Lingsoft - 30 years of Leading Language Management > > www.lingsoft.fi > > Speech Applications - Language Management - Translation - Reader's and > Writer's Tools - Text Tools - E-books and M-books > > Mikael Pesonen > System Engineer > > e-mail: mikael.peso...@lingsoft.fi > Tel. +358 2 279 3300 > > Time zone: GMT+2 > > Helsinki Office > Eteläranta 10 > FI-00130 Helsinki > FINLAND > > Turku Office > Kauppiaskatu 5 A > FI-20100 Turku > FINLAND >
