Re: [SMW-devel] [Semediawiki-user] s13n stands for semantification
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
Re: [SMW-devel] [Semediawiki-user] s13n stands for semantification
Hi Markus! Answers are inline - Yury Katkov, WikiVote On Fri, Nov 23, 2012 at 11:26 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: 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. I totally agree. These are high-level use cases of the data that is making available through the semantic properties: http://semantic-mediawiki.org/wiki/User:Yury_Katkov/s13n_stands_for_semantification . Do you mean them when you speak of use cases? Do we have to add any details or restructurize this page? 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
Re: [SMW-devel] [Semediawiki-user] s13n stands for semantification
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? 2) what is the priority of this task? 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. - 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
Re: [SMW-devel] [Semediawiki-user] s13n stands for semantification
On 16/11/12 14:32, Yury Katkov wrote: Hi Markus! That's very nice! How hard/long is that task? Unknown. First we need to decide what we want to have. We can now use something like SMWStore::updateDataBefore hook, but not good approach sometimes: with voting and history s13n you'll need to create a lot of property values each time the data is updated. When you semantify the page history you'll need to create several hundreds datavalues representing the revisions of the current page - that's too exprensive. The idea was to have data that is not governed by page updates. There are two basic designs: (1) We introduce something like named graphs. All data belongs to a graph. Only data in the default graph is updated with the page contents; other writing methods are provided for the rest. Maximally flexible, but some storage overhead. (2) We do not use graphs but bind this information to properties: some properties are governed by page contents, other properties are governed in other ways. Less flexible, but no storage overhead. Cheers, Markus - Yury Katkov, WikiVote On Fri, Nov 16, 2012 at 4:34 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On 16/11/12 11:27, Yury Katkov wrote: Hi everyone! I talked about the topic of semanticfication of the MediaWiki extension with a lot of people in SMWCon and saw the great interest to this topic. We have tried to describe the problem on this page: http://semantic-mediawiki.org/wiki/User:Yury_Katkov/s13n_stands_for_semantification To the users: if you're interested in topics of s13n and have the use case that is not described there - please describe it. To the developers: let's think together what's needed to be done in the SMW core to make s13n of the extensions cleaner and easier. Also the rough time/effort estimate would be great (maybe SMW companies can sponsor the development?) I have discussed this already with Jeroen. We can help to provide an infrastructure for this. However, the access paths for enabling efficient #ask queries are different from the traditional MW access paths to metadata, so all data that is to be s8ed (;-) will need to be replicated in SMW tables, even if the same MySQL DB is used. Cheers, Markus Cheers, Yury Katkov, WikiVote -- 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-user mailing list semediawiki-u...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-user -- 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
Re: [SMW-devel] [Semediawiki-user] s13n stands for semantification
Hi! Can you clarify the idea of named graphs a little bit? And what storage overhead we have in them? - Yury Katkov, WikiVote On Fri, Nov 16, 2012 at 7:33 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On 16/11/12 14:32, Yury Katkov wrote: Hi Markus! That's very nice! How hard/long is that task? Unknown. First we need to decide what we want to have. We can now use something like SMWStore::updateDataBefore hook, but not good approach sometimes: with voting and history s13n you'll need to create a lot of property values each time the data is updated. When you semantify the page history you'll need to create several hundreds datavalues representing the revisions of the current page - that's too exprensive. The idea was to have data that is not governed by page updates. There are two basic designs: (1) We introduce something like named graphs. All data belongs to a graph. Only data in the default graph is updated with the page contents; other writing methods are provided for the rest. Maximally flexible, but some storage overhead. (2) We do not use graphs but bind this information to properties: some properties are governed by page contents, other properties are governed in other ways. Less flexible, but no storage overhead. Cheers, Markus - Yury Katkov, WikiVote On Fri, Nov 16, 2012 at 4:34 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On 16/11/12 11:27, Yury Katkov wrote: Hi everyone! I talked about the topic of semanticfication of the MediaWiki extension with a lot of people in SMWCon and saw the great interest to this topic. We have tried to describe the problem on this page: http://semantic-mediawiki.org/wiki/User:Yury_Katkov/s13n_stands_for_semantification To the users: if you're interested in topics of s13n and have the use case that is not described there - please describe it. To the developers: let's think together what's needed to be done in the SMW core to make s13n of the extensions cleaner and easier. Also the rough time/effort estimate would be great (maybe SMW companies can sponsor the development?) I have discussed this already with Jeroen. We can help to provide an infrastructure for this. However, the access paths for enabling efficient #ask queries are different from the traditional MW access paths to metadata, so all data that is to be s8ed (;-) will need to be replicated in SMW tables, even if the same MySQL DB is used. Cheers, Markus Cheers, Yury Katkov, WikiVote -- 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-user mailing list semediawiki-u...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-user -- 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
Re: [SMW-devel] [Semediawiki-user] s13n stands for semantification
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
