On 18/11/12 13:30, Yury Katkov wrote: > Ok, I understand that: the choice is between to store or not to store > the source of the data by grouping the triples in graphs. Of course > it's up to core developers to choose. > Another set of questions: > 1) how the s13n's programming interfaces for extension developers will > look like?
Specifying this is a major part of the task. > 2) what is the priority of this task? I would say between 17 and 18. My (serious) point here is: priority must be relative. We have many requests for 1.9 (e.g. printouts for property chains and aggregates, paged query results, removing length restrictions on URL values, ...). The question is: what is the priority for doing this *before* any of these other, more long-standing requests? I think this can only be decided by collecting the main todos and then placing them in an order. > 3) Is it possible to sponsor the development to make it quicker? I > think that the companies interested in this feature can build together > a fund/grant to support the volunteer. WikiVote can definitely take > part in that sponsorship campaign. Thanks. A sponsored developer could help with specifying the requirements and producing technical documentation. The actual implementation is only possible after we know what we want to do. The project should start by collecting use-cases so that we get an idea of what we would need and how this new functionality could be invoked. Technically, the changes are blocked only by other changes in the store that are more urgent (further simplification of the table layout and data model, completion of the diff code). No other dependencies with ongoing SMW work is obvious to me now. Markus > ----- > Yury Katkov, WikiVote > > > > On Fri, Nov 16, 2012 at 9:35 PM, Jeroen De Dauw <jeroended...@gmail.com> > wrote: >> Hey, >> >> >>> Can you clarify the idea of named graphs a little bit? And what >>> storage overhead we have in them? >> >> >> Instead of having rows such as >> >> ( subject id, property id, value ) >> >> in the store, you instead have >> >> ( subject id, property id, value, graph id ) >> >> Of course our schema is more complex then this, but it's the same idea. >> >> Cheers >> >> -- >> Jeroen De Dauw >> http://www.bn2vs.com >> Don't panic. Don't be evil. >> -- > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
