From: Markus K. <ma...@se...> - 2011-10-03 09:02:54
|
Following up the discussions we had at SMWCon in Berlin, we have now implemented a new feature for "internal objects" in SMW. This email explains this feature and starts the discussion on some open questions for it to become stable. == Goal == Allow SMW annotations to refer to objects that have their own property-value pairs just like wiki pages, but that do not actually have an article in the wiki. This can be used to "group" property-value pairs given on one page without requiring new auxiliary pages to be created. It also integrates the main functionality of the Semantic Internal Objects (SIO) extension into SMW. == Feature Overview: Current Prototype Implementation == SMW now has a new "subobject" feature. For example, you can use the parserfunction #subobject on some page "Example page" as follows: {{#subobject:street address | street name=Parks Road | postcode=OX1 3QD | city=Oxford | country=UK }} This does the following: (A) create a new subobject called "Example page#_anInternalId", (B) assign the property values for "street name", ..., "country" to this subobject, (C) assign the subobject "Example page#_anInternalId" as a property value for "street address" to "Example page". You could have achieved a similar effect as follows: (A') create a new page called "my auxiliary page", (B') edit this new page to contain the text: [[street name::Parks Road]] [[postcode::OX1 3QD]] [[city::Oxford]] [[country::UK]] (C') edit the page "Example page" to contain the text: [[street address::my auxiliary page]] The difference when using #subobject is that you do not create a new auxiliary page. Instead, a subobject of "Example page" is created by SMW. Also, the function #subobject does not display anything unless an error occurred that needs to be reported. Subobjects are named automatically by following the schema "Parent page name#_someInternalId". When subobjects are displayed to users, they thus appear like links to sections within their parent page. This can happen, e.g., subobjects might occur in query results (example above: {{#ask: [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by this name "Parent page name#_someInternalId" in all search and export interfaces in SMW. For example, one can view the data for one particular subobject in Special:Browse. In general, subobjects should work like normal pages in most SMW interfaces. The goal of this naming is to avoid any clashes with real pages and with real sections in real pages while still allowing the same methods to be used. The feature can be tested in the current SVN version but it is still unstable and might change significantly (read on). == Relation to Semantic Internal Objects == The feature is very similar to the SIO extension. The difference is that in SIO, the main property ("street address" above) points from the subobject to the parent page. In the above example, "street address" really means "has street address" while in SIO it would be used like "is street address of". The other difference is that subobjects work with both SQL and RDF stores, are exported in RDF and are compatible with interfaces like Special:Browse. == Alternative Proposal == Instead of having a parser function that creates a subobject and assigns it to a property as a value, one could also have a parser function that only does the first thing and that *returns* a subobject for later use. This would require some further changes but it might be more elegant. For example, a call like {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }} would just "create" such an object and return its name (e.g. "Example_page#_someId"). Then one could use this name as a value to other properties, e.g.: [[street address::{{#subobject: street name=Parks Road | postcode=OX1 3QD | city=Oxford }}]] One advantage of this is that one could arbitrarily nest subobjects, i.e. use subobjects as property values when declaring other subobjects (SMW can already do this, just the input syntax does not support it). Another advantage is that subobjects could (optionally) be named instead of using the name generated by SMW now. For example, one could have {{#subobject:department_address |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} to create a subobject called "Example page#department_address" which could be used in other annotations on *any* page (this is already possible with subobjects now, but since their names are generated by SMW they might not be stable over time). In this case, it might be less desirable to return the name of the subobject. Overall, this alternative approach would allow subobjects to be used as first-class citizens of the SMW data space instead of viewing them as auxiliary objects for encoding compound property values. == Request for Comments == Feedback is welcome. The first question is which approach to subobjects should eventually be used. The follow-up question is how the respective parser function should be called. But there might also be completely different comments and questions. Cheers, Markus |
From: Dan B. <dan...@gm...> - 2011-10-03 09:52:49
|
On 3 October 2011 10:02, Markus Krötzsch <ma...@se...> wrote: > Following up the discussions we had at SMWCon in Berlin, we have now > implemented a new feature for "internal objects" in SMW. This email > explains this feature and starts the discussion on some open questions > for it to become stable. > > > == Goal == > > Allow SMW annotations to refer to objects that have their own > property-value pairs just like wiki pages, but that do not actually have > an article in the wiki. This can be used to "group" property-value pairs > given on one page without requiring new auxiliary pages to be created. > It also integrates the main functionality of the Semantic Internal > Objects (SIO) extension into SMW. > > > == Feature Overview: Current Prototype Implementation == > > SMW now has a new "subobject" feature. For example, you can use the > parserfunction #subobject on some page "Example page" as follows: > > {{#subobject:street address > | street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > | country=UK > }} > > This does the following: > > (A) create a new subobject called "Example page#_anInternalId", > (B) assign the property values for "street name", ..., "country" to this > subobject, > (C) assign the subobject "Example page#_anInternalId" as a property > value for "street address" to "Example page". > > You could have achieved a similar effect as follows: > > (A') create a new page called "my auxiliary page", > (B') edit this new page to contain the text: > > [[street name::Parks Road]] > [[postcode::OX1 3QD]] > [[city::Oxford]] > [[country::UK]] > > (C') edit the page "Example page" to contain the text: > > [[street address::my auxiliary page]] > > > The difference when using #subobject is that you do not create a new > auxiliary page. Instead, a subobject of "Example page" is created by > SMW. Also, the function #subobject does not display anything unless an > error occurred that needs to be reported. > > Subobjects are named automatically by following the schema "Parent page > name#_someInternalId". When subobjects are displayed to users, they thus > appear like links to sections within their parent page. This can happen, > e.g., subobjects might occur in query results (example above: {{#ask: > [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by > this name "Parent page name#_someInternalId" in all search and export > interfaces in SMW. For example, one can view the data for one particular > subobject in Special:Browse. > > In general, subobjects should work like normal pages in most SMW > interfaces. The goal of this naming is to avoid any clashes with real > pages and with real sections in real pages while still allowing the same > methods to be used. > > The feature can be tested in the current SVN version but it is still > unstable and might change significantly (read on). > > > == Relation to Semantic Internal Objects == > > The feature is very similar to the SIO extension. The difference is that > in SIO, the main property ("street address" above) points from the > subobject to the parent page. In the above example, "street address" > really means "has street address" while in SIO it would be used like "is > street address of". > > The other difference is that subobjects work with both SQL and RDF > stores, are exported in RDF and are compatible with interfaces like > Special:Browse. > > > == Alternative Proposal == > > Instead of having a parser function that creates a subobject and assigns > it to a property as a value, one could also have a parser function that > only does the first thing and that *returns* a subobject for later use. > This would require some further changes but it might be more elegant. > > For example, a call like > > {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > would just "create" such an object and return its name (e.g. > "Example_page#_someId"). Then one could use this name as a value to > other properties, e.g.: > > [[street address::{{#subobject: street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > }}]] > > One advantage of this is that one could arbitrarily nest subobjects, > i.e. use subobjects as property values when declaring other subobjects > (SMW can already do this, just the input syntax does not support it). > Another advantage is that subobjects could (optionally) be named instead > of using the name generated by SMW now. For example, one could have > > {{#subobject:department_address > |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > to create a subobject called "Example page#department_address" which > could be used in other annotations on *any* page (this is already > possible with subobjects now, but since their names are generated by SMW > they might not be stable over time). In this case, it might be less > desirable to return the name of the subobject. > > Overall, this alternative approach would allow subobjects to be used as > first-class citizens of the SMW data space instead of viewing them as > auxiliary objects for encoding compound property values. > > > == Request for Comments == > > Feedback is welcome. The first question is which approach to subobjects > should eventually be used. The follow-up question is how the respective > parser function should be called. But there might also be completely > different comments and questions. Thanks Markus, Perhaps a very dumb question, but what advantages are there to using subobjects over real pages? i.e. When is it recommended to use a subobject over a regular page? (That is, disregarding peoples sensibilities over 'too many' or 'messy' pages, which are purely subjective). Currently, the main reason I use SIO is because they work so nicely with multi-instance templates in SF, but this is a SF limitation rather than a decision driven by 'data design' or modelling considerations. (One form can only edit one page at a time). Probably this was discussed at SMWCon, but if there is no other permanent record you can point me at, it would be great if you could put the key points here. Cheers, Dan. > Cheers, > > Markus > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Markus K. <ma...@se...> - 2011-10-03 15:48:40
|
On 03/10/11 10:50, Dan Bolser wrote: ... > > Thanks Markus, > > Perhaps a very dumb question, but what advantages are there to using > subobjects over real pages? > > i.e. When is it recommended to use a subobject over a regular page? > (That is, disregarding peoples sensibilities over 'too many' or > 'messy' pages, which are purely subjective). > > Currently, the main reason I use SIO is because they work so nicely > with multi-instance templates in SF, but this is a SF limitation > rather than a decision driven by 'data design' or modelling > considerations. (One form can only edit one page at a time). > > Probably this was discussed at SMWCon, but if there is no other > permanent record you can point me at, it would be great if you could > put the key points here. There was not too much of a discussion about the general motivation. Subobjects are really just like pages as far as the structure of the stored data is concerned. However, there really are cases where the creation of a page would seem inappropriate, e.g., when the subobject merely groups two values. For example, you would not want pages for "300g butter or margarine". In other cases, the policy of the wiki might be to not have individual pages for some item, even if it could be argued for as an individual subject (like my address example). Subobjects let you handle such situations in a more flexible way. Regards, Markus |
From: zehetner <zeh...@mo...> - 2011-10-03 10:48:24
|
Would these subobjects interfere at some stage with the support of multi-value properties or replace them? Or will they remain an additional feature like the SIOs? Gu On Mon, 03 Oct 2011 10:02:32 +0100, Markus Krötzsch <ma...@se...> wrote: > Following up the discussions we had at SMWCon in Berlin, we have now > implemented a new feature for "internal objects" in SMW. This email > explains this feature and starts the discussion on some open questions > for it to become stable. > > > == Goal == > > Allow SMW annotations to refer to objects that have their own > property-value pairs just like wiki pages, but that do not actually have > an article in the wiki. This can be used to "group" property-value pairs > given on one page without requiring new auxiliary pages to be created. > It also integrates the main functionality of the Semantic Internal > Objects (SIO) extension into SMW. > > > == Feature Overview: Current Prototype Implementation == > > SMW now has a new "subobject" feature. For example, you can use the > parserfunction #subobject on some page "Example page" as follows: > > {{#subobject:street address > | street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > | country=UK > }} > > This does the following: > > (A) create a new subobject called "Example page#_anInternalId", > (B) assign the property values for "street name", ..., "country" to this > subobject, > (C) assign the subobject "Example page#_anInternalId" as a property > value for "street address" to "Example page". > > You could have achieved a similar effect as follows: > > (A') create a new page called "my auxiliary page", > (B') edit this new page to contain the text: > > [[street name::Parks Road]] > [[postcode::OX1 3QD]] > [[city::Oxford]] > [[country::UK]] > > (C') edit the page "Example page" to contain the text: > > [[street address::my auxiliary page]] > > > The difference when using #subobject is that you do not create a new > auxiliary page. Instead, a subobject of "Example page" is created by > SMW. Also, the function #subobject does not display anything unless an > error occurred that needs to be reported. > > Subobjects are named automatically by following the schema "Parent page > name#_someInternalId". When subobjects are displayed to users, they thus > appear like links to sections within their parent page. This can happen, > e.g., subobjects might occur in query results (example above: {{#ask: > [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by > this name "Parent page name#_someInternalId" in all search and export > interfaces in SMW. For example, one can view the data for one particular > subobject in Special:Browse. > > In general, subobjects should work like normal pages in most SMW > interfaces. The goal of this naming is to avoid any clashes with real > pages and with real sections in real pages while still allowing the same > methods to be used. > > The feature can be tested in the current SVN version but it is still > unstable and might change significantly (read on). > > > == Relation to Semantic Internal Objects == > > The feature is very similar to the SIO extension. The difference is that > in SIO, the main property ("street address" above) points from the > subobject to the parent page. In the above example, "street address" > really means "has street address" while in SIO it would be used like "is > street address of". > > The other difference is that subobjects work with both SQL and RDF > stores, are exported in RDF and are compatible with interfaces like > Special:Browse. > > > == Alternative Proposal == > > Instead of having a parser function that creates a subobject and assigns > it to a property as a value, one could also have a parser function that > only does the first thing and that *returns* a subobject for later use. > This would require some further changes but it might be more elegant. > > For example, a call like > > {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > would just "create" such an object and return its name (e.g. > "Example_page#_someId"). Then one could use this name as a value to > other properties, e.g.: > > [[street address::{{#subobject: street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > }}]] > > One advantage of this is that one could arbitrarily nest subobjects, > i.e. use subobjects as property values when declaring other subobjects > (SMW can already do this, just the input syntax does not support it). > Another advantage is that subobjects could (optionally) be named instead > of using the name generated by SMW now. For example, one could have > > {{#subobject:department_address > |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > to create a subobject called "Example page#department_address" which > could be used in other annotations on *any* page (this is already > possible with subobjects now, but since their names are generated by SMW > they might not be stable over time). In this case, it might be less > desirable to return the name of the subobject. > > Overall, this alternative approach would allow subobjects to be used as > first-class citizens of the SMW data space instead of viewing them as > auxiliary objects for encoding compound property values. > > > == Request for Comments == > > Feedback is welcome. The first question is which approach to subobjects > should eventually be used. The follow-up question is how the respective > parser function should be called. But there might also be completely > different comments and questions. > > > Cheers, > > Markus > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel |
From: Markus K. <ma...@se...> - 2011-10-03 15:51:56
|
On 03/10/11 11:48, zehetner wrote: > Would these subobjects interfere at some stage with the support of > multi-value properties or replace them? Or will they remain an additional > feature like the SIOs? Multi-valued properties in SMW 1.6 are already a special kind of subobject. Both kinds of subobject work well together (i.e., one can have Type:Record properties in subobjects). It is not planned to drop record support. Markus > On Mon, 03 Oct 2011 10:02:32 +0100, Markus Krötzsch > <ma...@se...> wrote: >> Following up the discussions we had at SMWCon in Berlin, we have now >> implemented a new feature for "internal objects" in SMW. This email >> explains this feature and starts the discussion on some open questions >> for it to become stable. >> >> >> == Goal == >> >> Allow SMW annotations to refer to objects that have their own >> property-value pairs just like wiki pages, but that do not actually have > >> an article in the wiki. This can be used to "group" property-value pairs > >> given on one page without requiring new auxiliary pages to be created. >> It also integrates the main functionality of the Semantic Internal >> Objects (SIO) extension into SMW. >> >> >> == Feature Overview: Current Prototype Implementation == >> >> SMW now has a new "subobject" feature. For example, you can use the >> parserfunction #subobject on some page "Example page" as follows: >> >> {{#subobject:street address >> | street name=Parks Road >> | postcode=OX1 3QD >> | city=Oxford >> | country=UK >> }} >> >> This does the following: >> >> (A) create a new subobject called "Example page#_anInternalId", >> (B) assign the property values for "street name", ..., "country" to this > >> subobject, >> (C) assign the subobject "Example page#_anInternalId" as a property >> value for "street address" to "Example page". >> >> You could have achieved a similar effect as follows: >> >> (A') create a new page called "my auxiliary page", >> (B') edit this new page to contain the text: >> >> [[street name::Parks Road]] >> [[postcode::OX1 3QD]] >> [[city::Oxford]] >> [[country::UK]] >> >> (C') edit the page "Example page" to contain the text: >> >> [[street address::my auxiliary page]] >> >> >> The difference when using #subobject is that you do not create a new >> auxiliary page. Instead, a subobject of "Example page" is created by >> SMW. Also, the function #subobject does not display anything unless an >> error occurred that needs to be reported. >> >> Subobjects are named automatically by following the schema "Parent page >> name#_someInternalId". When subobjects are displayed to users, they thus > >> appear like links to sections within their parent page. This can happen, > >> e.g., subobjects might occur in query results (example above: {{#ask: >> [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by >> this name "Parent page name#_someInternalId" in all search and export >> interfaces in SMW. For example, one can view the data for one particular > >> subobject in Special:Browse. >> >> In general, subobjects should work like normal pages in most SMW >> interfaces. The goal of this naming is to avoid any clashes with real >> pages and with real sections in real pages while still allowing the same > >> methods to be used. >> >> The feature can be tested in the current SVN version but it is still >> unstable and might change significantly (read on). >> >> >> == Relation to Semantic Internal Objects == >> >> The feature is very similar to the SIO extension. The difference is that > >> in SIO, the main property ("street address" above) points from the >> subobject to the parent page. In the above example, "street address" >> really means "has street address" while in SIO it would be used like "is > >> street address of". >> >> The other difference is that subobjects work with both SQL and RDF >> stores, are exported in RDF and are compatible with interfaces like >> Special:Browse. >> >> >> == Alternative Proposal == >> >> Instead of having a parser function that creates a subobject and assigns > >> it to a property as a value, one could also have a parser function that >> only does the first thing and that *returns* a subobject for later use. >> This would require some further changes but it might be more elegant. >> >> For example, a call like >> >> {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }} >> >> would just "create" such an object and return its name (e.g. >> "Example_page#_someId"). Then one could use this name as a value to >> other properties, e.g.: >> >> [[street address::{{#subobject: street name=Parks Road >> | postcode=OX1 3QD >> | city=Oxford >> }}]] >> >> One advantage of this is that one could arbitrarily nest subobjects, >> i.e. use subobjects as property values when declaring other subobjects >> (SMW can already do this, just the input syntax does not support it). >> Another advantage is that subobjects could (optionally) be named instead > >> of using the name generated by SMW now. For example, one could have >> >> {{#subobject:department_address >> |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} >> >> to create a subobject called "Example page#department_address" which >> could be used in other annotations on *any* page (this is already >> possible with subobjects now, but since their names are generated by SMW > >> they might not be stable over time). In this case, it might be less >> desirable to return the name of the subobject. >> >> Overall, this alternative approach would allow subobjects to be used as >> first-class citizens of the SMW data space instead of viewing them as >> auxiliary objects for encoding compound property values. >> >> >> == Request for Comments == >> >> Feedback is welcome. The first question is which approach to subobjects >> should eventually be used. The follow-up question is how the respective >> parser function should be called. But there might also be completely >> different comments and questions. >> >> >> Cheers, >> >> Markus >> >> >> > ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Dan B. <dan...@gm...> - 2011-10-03 18:22:58
|
On 3 October 2011 16:48, Markus Krötzsch <ma...@se...> wrote: > On 03/10/11 10:50, Dan Bolser wrote: > ... >> >> Thanks Markus, >> >> Perhaps a very dumb question, but what advantages are there to using >> subobjects over real pages? >> >> i.e. When is it recommended to use a subobject over a regular page? >> (That is, disregarding peoples sensibilities over 'too many' or >> 'messy' pages, which are purely subjective). >> >> Currently, the main reason I use SIO is because they work so nicely >> with multi-instance templates in SF, but this is a SF limitation >> rather than a decision driven by 'data design' or modelling >> considerations. (One form can only edit one page at a time). >> >> Probably this was discussed at SMWCon, but if there is no other >> permanent record you can point me at, it would be great if you could >> put the key points here. > > There was not too much of a discussion about the general motivation. > Subobjects are really just like pages as far as the structure of the stored > data is concerned. However, there really are cases where the creation of a > page would seem inappropriate, e.g., when the subobject merely groups two > values. For example, you would not want pages for "300g butter or > margarine". In other cases, the policy of the wiki might be to not have > individual pages for some item, even if it could be argued for as an > individual subject (like my address example). Subobjects let you handle such > situations in a more flexible way. I definately see the advantage when it comes to linking specific quantities with types, as quantities are infinitely variable, you wouldn't wan't a page for every specific permutation. Now I'm thinking about having [[butter::600g]] ... I guess it's good to have more than one way to do things. Overall it does 'feel tidier' to have a simple set of content pages rather than many arbitrary 'data pages', but I'm just looking for a way to quantify it. (After all, users are likely to stick to content pages if that is where your site design keeps them). I guess two suggested guidelines come to mind: 1) The subobject should be strictly dependent on its parent object, i.e. it only makes sense to store the data for that subobject on the parent page, and the data shouldn't be duplicated elsewhere (very often). 2) There should never be a need to add free text or otherwise discuss the subobject separately from the parent page (which stems from point 1 I guess). Cheers, Dan. > Regards, > > Markus > > > |
From: Markus K. <ma...@se...> - 2011-10-04 07:06:01
|
On 03/10/11 19:22, Dan Bolser wrote: > On 3 October 2011 16:48, Markus Krötzsch<ma...@se...> wrote: >> On 03/10/11 10:50, Dan Bolser wrote: >> ... >>> >>> Thanks Markus, >>> >>> Perhaps a very dumb question, but what advantages are there to using >>> subobjects over real pages? >>> >>> i.e. When is it recommended to use a subobject over a regular page? >>> (That is, disregarding peoples sensibilities over 'too many' or >>> 'messy' pages, which are purely subjective). >>> >>> Currently, the main reason I use SIO is because they work so nicely >>> with multi-instance templates in SF, but this is a SF limitation >>> rather than a decision driven by 'data design' or modelling >>> considerations. (One form can only edit one page at a time). >>> >>> Probably this was discussed at SMWCon, but if there is no other >>> permanent record you can point me at, it would be great if you could >>> put the key points here. >> >> There was not too much of a discussion about the general motivation. >> Subobjects are really just like pages as far as the structure of the stored >> data is concerned. However, there really are cases where the creation of a >> page would seem inappropriate, e.g., when the subobject merely groups two >> values. For example, you would not want pages for "300g butter or >> margarine". In other cases, the policy of the wiki might be to not have >> individual pages for some item, even if it could be argued for as an >> individual subject (like my address example). Subobjects let you handle such >> situations in a more flexible way. > > I definately see the advantage when it comes to linking specific > quantities with types, as quantities are infinitely variable, you > wouldn't wan't a page for every specific permutation. > > Now I'm thinking about having [[butter::600g]] ... I guess it's good > to have more than one way to do things. > > Overall it does 'feel tidier' to have a simple set of content pages > rather than many arbitrary 'data pages', but I'm just looking for a > way to quantify it. (After all, users are likely to stick to content > pages if that is where your site design keeps them). > > I guess two suggested guidelines come to mind: > > 1) The subobject should be strictly dependent on its parent object, > i.e. it only makes sense to store the data for that subobject on the > parent page, and the data shouldn't be duplicated elsewhere (very > often). > > 2) There should never be a need to add free text or otherwise discuss > the subobject separately from the parent page (which stems from point > 1 I guess). Yes, these are possible guidelines. In the end, I would expect the policies of each wiki to be different there (compare the Wikipedias' various policies about the articles that one should/shouldn't have). An advantage of data objects is that they lead to the same data structure as the creation of new pages. So both approaches are fully compatible in queries and one does not have to decide for one or the other approach consistently to make things work. One could even have a mixed approach where some subobjects are promoted to standalone pages when there is sufficient interest to write about them. Regards, Markus |
From: Gregor H. <g.m...@gm...> - 2011-10-05 14:03:46
|
> Overall it does 'feel tidier' to have a simple set of content pages > rather than many arbitrary 'data pages', but I'm just looking for a > way to quantify it. (After all, users are likely to stick to content > pages if that is where your site design keeps them). Our arguments for using subobjects (presently SIOs) are: * there is not semantic forms support * raw editing of a case where a pest occurs on 10 hosts in some of 100 countries, resulting in perhaps 300 pest-host-country tupels would be impossible with separate pages. * mediawiki has no distinction between content pages and data pages (one could use a new ns though) Raw wikitext editing is a value in itself. Support in Semantic forms for data pages would enable using this method at all. But the reverse question would be: Is there an advantage to put things that have no true identifier and no independent existence on arbitrarily created mediawiki pages? Gregor |
From: John M. <jmc...@hy...> - 2011-10-03 21:01:44
|
Markus, #subobject is great to hear about, though I look at http://semantic-mediawiki.org/wiki/Special:Version and I don't see it yet listed as a parser function; is there a schedule in mind for public testing? And I'm not understanding how records are still useful given #subobject's availability -- are records to become a backwards-compatibility thing? Anyway to give you a feel for my own perspective, I'm working to allow users via forms to associate a page with attributes possibly annotated with, for instance, provenance info. I store these attribute annotations in Dublin Core properties within an attribute object attached to the page. Of course users are not constrained at the same time from annotating a page's content directly. I then had a choice between implementing the attribute objects as records or as sio's - I chose SIO primarily because it preserves basic #ask syntax, thank you Yaron, which can be used in compound queries. Your note says to me though that you're reimplementing records to be amenable to basic ask syntax (plus other goodies you mention). It'd help my understanding alot to contrast use cases for various queries that retrieve * all subobjects in the wiki with a particular property &or value * all pages in the wiki with a subobject having a particular property &or value * the container subobject for a given nested subobject * the container page for a given subobject or a given nested subobject Other notes: # re:Browse * can subobjects be shown (in a subtable) on special:browse/Example_page, not separate browse pages for each subobject # re:#subobject syntax * I definitely prefer {{#set:pageprop={{#subobject: objname|prop1=val1|...}}}} * I'd like to store a formatting template name in the subobject too (see below), eg {{#set:pageprop={{#subobject: objname|templatename|prop1=val1|...}}}} # re:subobject annotations * I much would like the object to preserve implicit formatting provided by a modified syntax for instance: [[[address::[[bldgnbr::123]] [[street name::Parks Road]], [[city::Oxford]] [[postcode::OX1 3QD]] [[country::UK]] ]]] which would be output by {{#show:{{FULLPAGENAME}}|?address=}} # re: ask templates * can the param value for a subobject property optionally be its name OR its formatted OR unformatted content Bottom line, it's really good to see SIO functionality moved into core SMW. Thanks, John |
From: Markus K. <ma...@se...> - 2011-10-04 07:38:21
|
On 03/10/11 22:58, John McClure wrote: > Markus, > #subobject is great to hear about, though I look at > http://semantic-mediawiki.org/wiki/Special:Version and I don't see it yet > listed as a parser function; is there a schedule in mind for public testing? > And I'm not understanding how records are still useful given #subobject's > availability -- are records to become a backwards-compatibility thing? Records are an independent feature that is not under discussion right now. The fact that records largely are based on the same internal mechanisms as subobects reduces the cost of keeping them in the code. > > Anyway to give you a feel for my own perspective, I'm working to allow users > via forms to associate a page with attributes possibly annotated with, for > instance, provenance info. I store these attribute annotations in Dublin > Core properties within an attribute object attached to the page. Of course > users are not constrained at the same time from annotating a page's content > directly. I then had a choice between implementing the attribute objects as > records or as sio's - I chose SIO primarily because it preserves basic #ask > syntax, thank you Yaron, which can be used in compound queries. > > Your note says to me though that you're reimplementing records to be > amenable to basic ask syntax (plus other goodies you mention). This should already be the case. Records are stored like subobjects with a fixed list of properties. So they can be queried in the same way too. > It'd help my > understanding alot to contrast use cases for various queries that retrieve > > * all subobjects in the wiki with a particular property&or value There is no distinction between subobjects and normal pages. You can find all things that have a particular property or property value but you cannot filter this to only get subobjects (and no pages that match the query). > * all pages in the wiki with a subobject having a particular property&or > value > * the container subobject for a given nested subobject > * the container page for a given subobject or a given nested subobject These are all easy to do, just as one would do the same queries for pages. Again, there is no distinction between pages and subobjects, so there is no difference between the last two queries. Also note that, with the currently implemented parserfunction, you cannot create nested subobjects for lack of syntax. > > Other notes: > # re:Browse > * can subobjects be shown (in a subtable) on special:browse/Example_page, > not separate browse pages for each subobject Possible, but this would need a new interface. Special:Browse is not suitable for displaying nested property values (otherwise, one could do a similar thing for arbitrary pages, not just for subobjects). > > # re:#subobject syntax > * I definitely prefer {{#set:pageprop={{#subobject: > objname|prop1=val1|...}}}} Yes, I also find this more logical. > * I'd like to store a formatting template name in the subobject too (see > below), eg > {{#set:pageprop={{#subobject: objname|templatename|prop1=val1|...}}}} SMW does not support this since one can already achieve the same thing by using a formatting template instead of #subobject, and use #subobject within the template. We would like to leave formatting to MediaWiki and keep the task of SMW to be data management. > > # re:subobject annotations > * I much would like the object to preserve implicit formatting provided by a > modified syntax for instance: > [[[address::[[bldgnbr::123]] [[street name::Parks Road]], [[city::Oxford]] > [[postcode::OX1 3QD]] [[country::UK]] ]]] > which would be output by {{#show:{{FULLPAGENAME}}|?address=}} This is not possible with SMW unless one would change the data model in a quite fundamental fashion. Data in SMW is independent of formatting and of the order in which it was given on a page. This basic data model is the same for subobjects. Also, the above syntax with nested [[ ]] does not work in SMW since we are lacking an efficient way to parse this (there is a switch to enable this but this does not work with longer pages unless the Perl regexp library in PHP became a lot more efficient since I last tested it). However, you can store formatted strings of wikitext like "address" in your above example by using a property of Type:Text in #set. Using a template, one could therefore store both the formatted address and the subobject that is based on this data. Another solution would be to create pages with the formatted content and to transclude them whenever the original formatting is desired. > > # re: ask templates > * can the param value for a subobject property optionally be its name OR its > formatted OR unformatted content I don't think I understand what you mean here. But maybe this is already moot given that formatting is not part of the stored data? > > Bottom line, it's really good to see SIO functionality moved into core SMW. Yes, I have been convinced that many users want this. Regards, Markus |
From: CW D. <cwd...@gm...> - 2011-10-04 01:50:30
|
Markus, Thanks for taking this on. I talked myself out of both solutions three times, just in the span of writing a response. This is a tough problem, I think. So, what niggles at me is whether it is reasonable to argue for solution 1 or solution 2 based on whether the "something" in the middle is real or abstract? I mean, you gave an example using an address but Yaron usually talks about N-ary relations using a recipe analogy. An address is a real thing that exists irregardless of where it's mentioned in the wiki and the address has parts (which also have some sort of relatedness in the real world). I think that in the case of the address, it would be OK to make a wiki page for that data--12 Downing Street is relevant even if the PM moves to 14 Downing St, because it's still a real place. It's relevant because some person or business occupies (or "Has") that address. Whereas the recipe example (quantity+ingredient) is more of an adverb+verb combination and they are only relevant to each other in the specific instance (and completely meaningless outside of the recipe context). "500g of flour" would never deserve its own wiki page. I think solution 1 suits the real case better but, would work for both cases. Solution 2 really only works for the abstract case. However, since the real case can be solved by making a wiki page but the abstract case cannot, maybe solution 2 is the preferable option. That way,people won't go around NOT making wiki pages about things that really ought to have pages made about them. -Clarence On Mon, Oct 3, 2011 at 5:02 AM, Markus Krötzsch < ma...@se...> wrote: > Following up the discussions we had at SMWCon in Berlin, we have now > implemented a new feature for "internal objects" in SMW. This email > explains this feature and starts the discussion on some open questions > for it to become stable. > > > == Goal == > > Allow SMW annotations to refer to objects that have their own > property-value pairs just like wiki pages, but that do not actually have > an article in the wiki. This can be used to "group" property-value pairs > given on one page without requiring new auxiliary pages to be created. > It also integrates the main functionality of the Semantic Internal > Objects (SIO) extension into SMW. > > > == Feature Overview: Current Prototype Implementation == > > SMW now has a new "subobject" feature. For example, you can use the > parserfunction #subobject on some page "Example page" as follows: > > {{#subobject:street address > | street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > | country=UK > }} > > This does the following: > > (A) create a new subobject called "Example page#_anInternalId", > (B) assign the property values for "street name", ..., "country" to this > subobject, > (C) assign the subobject "Example page#_anInternalId" as a property > value for "street address" to "Example page". > > You could have achieved a similar effect as follows: > > (A') create a new page called "my auxiliary page", > (B') edit this new page to contain the text: > > [[street name::Parks Road]] > [[postcode::OX1 3QD]] > [[city::Oxford]] > [[country::UK]] > > (C') edit the page "Example page" to contain the text: > > [[street address::my auxiliary page]] > > > The difference when using #subobject is that you do not create a new > auxiliary page. Instead, a subobject of "Example page" is created by > SMW. Also, the function #subobject does not display anything unless an > error occurred that needs to be reported. > > Subobjects are named automatically by following the schema "Parent page > name#_someInternalId". When subobjects are displayed to users, they thus > appear like links to sections within their parent page. This can happen, > e.g., subobjects might occur in query results (example above: {{#ask: > [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by > this name "Parent page name#_someInternalId" in all search and export > interfaces in SMW. For example, one can view the data for one particular > subobject in Special:Browse. > > In general, subobjects should work like normal pages in most SMW > interfaces. The goal of this naming is to avoid any clashes with real > pages and with real sections in real pages while still allowing the same > methods to be used. > > The feature can be tested in the current SVN version but it is still > unstable and might change significantly (read on). > > > == Relation to Semantic Internal Objects == > > The feature is very similar to the SIO extension. The difference is that > in SIO, the main property ("street address" above) points from the > subobject to the parent page. In the above example, "street address" > really means "has street address" while in SIO it would be used like "is > street address of". > > The other difference is that subobjects work with both SQL and RDF > stores, are exported in RDF and are compatible with interfaces like > Special:Browse. > > > == Alternative Proposal == > > Instead of having a parser function that creates a subobject and assigns > it to a property as a value, one could also have a parser function that > only does the first thing and that *returns* a subobject for later use. > This would require some further changes but it might be more elegant. > > For example, a call like > > {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > would just "create" such an object and return its name (e.g. > "Example_page#_someId"). Then one could use this name as a value to > other properties, e.g.: > > [[street address::{{#subobject: street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > }}]] > > One advantage of this is that one could arbitrarily nest subobjects, > i.e. use subobjects as property values when declaring other subobjects > (SMW can already do this, just the input syntax does not support it). > Another advantage is that subobjects could (optionally) be named instead > of using the name generated by SMW now. For example, one could have > > {{#subobject:department_address > |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > to create a subobject called "Example page#department_address" which > could be used in other annotations on *any* page (this is already > possible with subobjects now, but since their names are generated by SMW > they might not be stable over time). In this case, it might be less > desirable to return the name of the subobject. > > Overall, this alternative approach would allow subobjects to be used as > first-class citizens of the SMW data space instead of viewing them as > auxiliary objects for encoding compound property values. > > > == Request for Comments == > > Feedback is welcome. The first question is which approach to subobjects > should eventually be used. The follow-up question is how the respective > parser function should be called. But there might also be completely > different comments and questions. > > > Cheers, > > Markus > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Markus K. <ma...@se...> - 2011-10-04 07:49:35
|
Hi Clarence, I agree that the implications for modelling are not easy to see in general. The distinction you make between proper objects (i.e., property values that are connected by an object) and n-ary relations (i.e., property values that are related in a given context) is important for developing modelling guidelines. However, at the moment I would rather like to retreat to a purely technical perspective to decide how the "wikitext programmer" should invoke SMW's subobject features. What these subobjects represent in the application context of a wiki remains the decision of the people who use them (just like with any SMW annotation). SMW can only provide structure, not grounding. Regards, Markus On 04/10/11 02:50, CW Dillon wrote: > Markus, > Thanks for taking this on. I talked myself out of both solutions three > times, just in the span of writing a response. This is a tough problem, > I think. So, what niggles at me is whether it is reasonable to argue for > solution 1 or solution 2 based on whether the "something" in the middle > is real or abstract? > > I mean, you gave an example using an address but Yaron usually talks > about N-ary relations using a recipe analogy. An address is a real thing > that exists irregardless of where it's mentioned in the wiki and the > address has parts (which also have some sort of relatedness in the real > world). I think that in the case of the address, it would be OK to make > a wiki page for that data--12 Downing Street is relevant even if the PM > moves to 14 Downing St, because it's still a real place. It's relevant > because some person or business occupies (or "Has") that address. > > Whereas the recipe example (quantity+ingredient) is more of an > adverb+verb combination and they are only relevant to each other in the > specific instance (and completely meaningless outside of the recipe > context). "500g of flour" would never deserve its own wiki page. > > I think solution 1 suits the real case better but, would work for both > cases. Solution 2 really only works for the abstract case. However, > since the real case can be solved by making a wiki page but the abstract > case cannot, maybe solution 2 is the preferable option. That way,people > won't go around NOT making wiki pages about things that really ought to > have pages made about them. > > -Clarence > > > > On Mon, Oct 3, 2011 at 5:02 AM, Markus Krötzsch > <ma...@se... <mailto:ma...@se...>> > wrote: > > Following up the discussions we had at SMWCon in Berlin, we have now > implemented a new feature for "internal objects" in SMW. This email > explains this feature and starts the discussion on some open questions > for it to become stable. > > > == Goal == > > Allow SMW annotations to refer to objects that have their own > property-value pairs just like wiki pages, but that do not actually have > an article in the wiki. This can be used to "group" property-value pairs > given on one page without requiring new auxiliary pages to be created. > It also integrates the main functionality of the Semantic Internal > Objects (SIO) extension into SMW. > > > == Feature Overview: Current Prototype Implementation == > > SMW now has a new "subobject" feature. For example, you can use the > parserfunction #subobject on some page "Example page" as follows: > > {{#subobject:street address > | street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > | country=UK > }} > > This does the following: > > (A) create a new subobject called "Example page#_anInternalId", > (B) assign the property values for "street name", ..., "country" to this > subobject, > (C) assign the subobject "Example page#_anInternalId" as a property > value for "street address" to "Example page". > > You could have achieved a similar effect as follows: > > (A') create a new page called "my auxiliary page", > (B') edit this new page to contain the text: > > [[street name::Parks Road]] > [[postcode::OX1 3QD]] > [[city::Oxford]] > [[country::UK]] > > (C') edit the page "Example page" to contain the text: > > [[street address::my auxiliary page]] > > > The difference when using #subobject is that you do not create a new > auxiliary page. Instead, a subobject of "Example page" is created by > SMW. Also, the function #subobject does not display anything unless an > error occurred that needs to be reported. > > Subobjects are named automatically by following the schema "Parent page > name#_someInternalId". When subobjects are displayed to users, they thus > appear like links to sections within their parent page. This can happen, > e.g., subobjects might occur in query results (example above: {{#ask: > [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by > this name "Parent page name#_someInternalId" in all search and export > interfaces in SMW. For example, one can view the data for one particular > subobject in Special:Browse. > > In general, subobjects should work like normal pages in most SMW > interfaces. The goal of this naming is to avoid any clashes with real > pages and with real sections in real pages while still allowing the same > methods to be used. > > The feature can be tested in the current SVN version but it is still > unstable and might change significantly (read on). > > > == Relation to Semantic Internal Objects == > > The feature is very similar to the SIO extension. The difference is that > in SIO, the main property ("street address" above) points from the > subobject to the parent page. In the above example, "street address" > really means "has street address" while in SIO it would be used like "is > street address of". > > The other difference is that subobjects work with both SQL and RDF > stores, are exported in RDF and are compatible with interfaces like > Special:Browse. > > > == Alternative Proposal == > > Instead of having a parser function that creates a subobject and assigns > it to a property as a value, one could also have a parser function that > only does the first thing and that *returns* a subobject for later use. > This would require some further changes but it might be more elegant. > > For example, a call like > > {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > would just "create" such an object and return its name (e.g. > "Example_page#_someId"). Then one could use this name as a value to > other properties, e.g.: > > [[street address::{{#subobject: street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > }}]] > > One advantage of this is that one could arbitrarily nest subobjects, > i.e. use subobjects as property values when declaring other subobjects > (SMW can already do this, just the input syntax does not support it). > Another advantage is that subobjects could (optionally) be named instead > of using the name generated by SMW now. For example, one could have > > {{#subobject:department_address > |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > to create a subobject called "Example page#department_address" which > could be used in other annotations on *any* page (this is already > possible with subobjects now, but since their names are generated by SMW > they might not be stable over time). In this case, it might be less > desirable to return the name of the subobject. > > Overall, this alternative approach would allow subobjects to be used as > first-class citizens of the SMW data space instead of viewing them as > auxiliary objects for encoding compound property values. > > > == Request for Comments == > > Feedback is welcome. The first question is which approach to subobjects > should eventually be used. The follow-up question is how the respective > parser function should be called. But there might also be completely > different comments and questions. > > > Cheers, > > Markus > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > <mailto:Sem...@li...> > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > |
From: Jesse W. <wj...@gm...> - 2011-10-05 19:16:48
|
Clarence, I regard your distinction between "address" and "recipe" as a practical modeling choice, it is case by case as you said. If "500g of flour" or "a teaspoon of sugar" is used often enough, maybe it makes sense to create a page for it, and you can add extra properties to it such as calories... Back to the choices. I favor #2. As Markus said, it looks elegant, and inline with existing SMW syntax. Moreover, it feels to be Object Oriented, and you can parse it and treat it as an object so that you can develop API, and further some kind of semantic object editor, to handle it. The fact that it can be nested is also big, it opens opportunities. Parsing and replacing text may also be easier. Say, one day, you decide to change "Street Address" into "Physical Address" then parsing and replacing existing properties should be easier - does not have to go to all "#subobject" parser functions to do it... Jesse On Mon, Oct 3, 2011 at 6:50 PM, CW Dillon <cwd...@gm...> wrote: > Markus, > Thanks for taking this on. I talked myself out of both solutions three > times, just in the span of writing a response. This is a tough problem, I > think. So, what niggles at me is whether it is reasonable to argue for > solution 1 or solution 2 based on whether the "something" in the middle is > real or abstract? > > I mean, you gave an example using an address but Yaron usually talks about > N-ary relations using a recipe analogy. An address is a real thing that > exists irregardless of where it's mentioned in the wiki and the address has > parts (which also have some sort of relatedness in the real world). I think > that in the case of the address, it would be OK to make a wiki page for that > data--12 Downing Street is relevant even if the PM moves to 14 Downing St, > because it's still a real place. It's relevant because some person or > business occupies (or "Has") that address. > > Whereas the recipe example (quantity+ingredient) is more of an adverb+verb > combination and they are only relevant to each other in the specific > instance (and completely meaningless outside of the recipe context). "500g > of flour" would never deserve its own wiki page. > > I think solution 1 suits the real case better but, would work for both > cases. Solution 2 really only works for the abstract case. However, since > the real case can be solved by making a wiki page but the abstract case > cannot, maybe solution 2 is the preferable option. That way,people won't go > around NOT making wiki pages about things that really ought to have pages > made about them. > > -Clarence > > > > On Mon, Oct 3, 2011 at 5:02 AM, Markus Krötzsch < > ma...@se...> wrote: > >> Following up the discussions we had at SMWCon in Berlin, we have now >> implemented a new feature for "internal objects" in SMW. This email >> explains this feature and starts the discussion on some open questions >> for it to become stable. >> >> >> == Goal == >> >> Allow SMW annotations to refer to objects that have their own >> property-value pairs just like wiki pages, but that do not actually have >> an article in the wiki. This can be used to "group" property-value pairs >> given on one page without requiring new auxiliary pages to be created. >> It also integrates the main functionality of the Semantic Internal >> Objects (SIO) extension into SMW. >> >> >> == Feature Overview: Current Prototype Implementation == >> >> SMW now has a new "subobject" feature. For example, you can use the >> parserfunction #subobject on some page "Example page" as follows: >> >> {{#subobject:street address >> | street name=Parks Road >> | postcode=OX1 3QD >> | city=Oxford >> | country=UK >> }} >> >> This does the following: >> >> (A) create a new subobject called "Example page#_anInternalId", >> (B) assign the property values for "street name", ..., "country" to this >> subobject, >> (C) assign the subobject "Example page#_anInternalId" as a property >> value for "street address" to "Example page". >> >> You could have achieved a similar effect as follows: >> >> (A') create a new page called "my auxiliary page", >> (B') edit this new page to contain the text: >> >> [[street name::Parks Road]] >> [[postcode::OX1 3QD]] >> [[city::Oxford]] >> [[country::UK]] >> >> (C') edit the page "Example page" to contain the text: >> >> [[street address::my auxiliary page]] >> >> >> The difference when using #subobject is that you do not create a new >> auxiliary page. Instead, a subobject of "Example page" is created by >> SMW. Also, the function #subobject does not display anything unless an >> error occurred that needs to be reported. >> >> Subobjects are named automatically by following the schema "Parent page >> name#_someInternalId". When subobjects are displayed to users, they thus >> appear like links to sections within their parent page. This can happen, >> e.g., subobjects might occur in query results (example above: {{#ask: >> [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by >> this name "Parent page name#_someInternalId" in all search and export >> interfaces in SMW. For example, one can view the data for one particular >> subobject in Special:Browse. >> >> In general, subobjects should work like normal pages in most SMW >> interfaces. The goal of this naming is to avoid any clashes with real >> pages and with real sections in real pages while still allowing the same >> methods to be used. >> >> The feature can be tested in the current SVN version but it is still >> unstable and might change significantly (read on). >> >> >> == Relation to Semantic Internal Objects == >> >> The feature is very similar to the SIO extension. The difference is that >> in SIO, the main property ("street address" above) points from the >> subobject to the parent page. In the above example, "street address" >> really means "has street address" while in SIO it would be used like "is >> street address of". >> >> The other difference is that subobjects work with both SQL and RDF >> stores, are exported in RDF and are compatible with interfaces like >> Special:Browse. >> >> >> == Alternative Proposal == >> >> Instead of having a parser function that creates a subobject and assigns >> it to a property as a value, one could also have a parser function that >> only does the first thing and that *returns* a subobject for later use. >> This would require some further changes but it might be more elegant. >> >> For example, a call like >> >> {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }} >> >> would just "create" such an object and return its name (e.g. >> "Example_page#_someId"). Then one could use this name as a value to >> other properties, e.g.: >> >> [[street address::{{#subobject: street name=Parks Road >> | postcode=OX1 3QD >> | city=Oxford >> }}]] >> >> One advantage of this is that one could arbitrarily nest subobjects, >> i.e. use subobjects as property values when declaring other subobjects >> (SMW can already do this, just the input syntax does not support it). >> Another advantage is that subobjects could (optionally) be named instead >> of using the name generated by SMW now. For example, one could have >> >> {{#subobject:department_address >> |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} >> >> to create a subobject called "Example page#department_address" which >> could be used in other annotations on *any* page (this is already >> possible with subobjects now, but since their names are generated by SMW >> they might not be stable over time). In this case, it might be less >> desirable to return the name of the subobject. >> >> Overall, this alternative approach would allow subobjects to be used as >> first-class citizens of the SMW data space instead of viewing them as >> auxiliary objects for encoding compound property values. >> >> >> == Request for Comments == >> >> Feedback is welcome. The first question is which approach to subobjects >> should eventually be used. The follow-up question is how the respective >> parser function should be called. But there might also be completely >> different comments and questions. >> >> >> Cheers, >> >> Markus >> >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> _______________________________________________ >> Semediawiki-user mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >> > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > |
From: CW D. <cwd...@gm...> - 2011-10-06 15:09:25
|
Jesse, Ooh. I hadn't thought of that, with the recipe example. You're right. ...there's always so much more that can be done! So, in addition to the "elegance" of option #2 is the flexibility of not *needing* an interim object to get at it's data. If a data page is desired/required, it can be created. OK. I'm convinced but, I'm only a user. Markus, Which way are you leaning? -Clarence On Wed, Oct 5, 2011 at 3:16 PM, Jesse Wang <wj...@gm...> wrote: > Clarence, I regard your distinction between "address" and "recipe" as a > practical modeling choice, it is case by case as you said. If "500g of > flour" or "a teaspoon of sugar" is used often enough, maybe it makes sense > to create a page for it, and you can add extra properties to it such as > calories... > > Back to the choices. I favor #2. As Markus said, it looks elegant, and > inline with existing SMW syntax. Moreover, it feels to be Object Oriented, > and you can parse it and treat it as an object so that you can develop API, > and further some kind of semantic object editor, to handle it. The fact that > it can be nested is also big, it opens opportunities. Parsing and replacing > text may also be easier. Say, one day, you decide to change "Street Address" > into "Physical Address" then parsing and replacing existing properties > should be easier - does not have to go to all "#subobject" parser functions > to do it... > > Jesse > > On Mon, Oct 3, 2011 at 6:50 PM, CW Dillon <cwd...@gm...> wrote: > >> Markus, >> Thanks for taking this on. I talked myself out of both solutions three >> times, just in the span of writing a response. This is a tough problem, I >> think. So, what niggles at me is whether it is reasonable to argue for >> solution 1 or solution 2 based on whether the "something" in the middle is >> real or abstract? >> >> I mean, you gave an example using an address but Yaron usually talks about >> N-ary relations using a recipe analogy. An address is a real thing that >> exists irregardless of where it's mentioned in the wiki and the address has >> parts (which also have some sort of relatedness in the real world). I think >> that in the case of the address, it would be OK to make a wiki page for that >> data--12 Downing Street is relevant even if the PM moves to 14 Downing St, >> because it's still a real place. It's relevant because some person or >> business occupies (or "Has") that address. >> >> Whereas the recipe example (quantity+ingredient) is more of an adverb+verb >> combination and they are only relevant to each other in the specific >> instance (and completely meaningless outside of the recipe context). "500g >> of flour" would never deserve its own wiki page. >> >> I think solution 1 suits the real case better but, would work for both >> cases. Solution 2 really only works for the abstract case. However, since >> the real case can be solved by making a wiki page but the abstract case >> cannot, maybe solution 2 is the preferable option. That way,people won't go >> around NOT making wiki pages about things that really ought to have pages >> made about them. >> >> -Clarence >> >> >> >> On Mon, Oct 3, 2011 at 5:02 AM, Markus Krötzsch < >> ma...@se...> wrote: >> >>> Following up the discussions we had at SMWCon in Berlin, we have now >>> implemented a new feature for "internal objects" in SMW. This email >>> explains this feature and starts the discussion on some open questions >>> for it to become stable. >>> >>> >>> == Goal == >>> >>> Allow SMW annotations to refer to objects that have their own >>> property-value pairs just like wiki pages, but that do not actually have >>> an article in the wiki. This can be used to "group" property-value pairs >>> given on one page without requiring new auxiliary pages to be created. >>> It also integrates the main functionality of the Semantic Internal >>> Objects (SIO) extension into SMW. >>> >>> >>> == Feature Overview: Current Prototype Implementation == >>> >>> SMW now has a new "subobject" feature. For example, you can use the >>> parserfunction #subobject on some page "Example page" as follows: >>> >>> {{#subobject:street address >>> | street name=Parks Road >>> | postcode=OX1 3QD >>> | city=Oxford >>> | country=UK >>> }} >>> >>> This does the following: >>> >>> (A) create a new subobject called "Example page#_anInternalId", >>> (B) assign the property values for "street name", ..., "country" to this >>> subobject, >>> (C) assign the subobject "Example page#_anInternalId" as a property >>> value for "street address" to "Example page". >>> >>> You could have achieved a similar effect as follows: >>> >>> (A') create a new page called "my auxiliary page", >>> (B') edit this new page to contain the text: >>> >>> [[street name::Parks Road]] >>> [[postcode::OX1 3QD]] >>> [[city::Oxford]] >>> [[country::UK]] >>> >>> (C') edit the page "Example page" to contain the text: >>> >>> [[street address::my auxiliary page]] >>> >>> >>> The difference when using #subobject is that you do not create a new >>> auxiliary page. Instead, a subobject of "Example page" is created by >>> SMW. Also, the function #subobject does not display anything unless an >>> error occurred that needs to be reported. >>> >>> Subobjects are named automatically by following the schema "Parent page >>> name#_someInternalId". When subobjects are displayed to users, they thus >>> appear like links to sections within their parent page. This can happen, >>> e.g., subobjects might occur in query results (example above: {{#ask: >>> [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by >>> this name "Parent page name#_someInternalId" in all search and export >>> interfaces in SMW. For example, one can view the data for one particular >>> subobject in Special:Browse. >>> >>> In general, subobjects should work like normal pages in most SMW >>> interfaces. The goal of this naming is to avoid any clashes with real >>> pages and with real sections in real pages while still allowing the same >>> methods to be used. >>> >>> The feature can be tested in the current SVN version but it is still >>> unstable and might change significantly (read on). >>> >>> >>> == Relation to Semantic Internal Objects == >>> >>> The feature is very similar to the SIO extension. The difference is that >>> in SIO, the main property ("street address" above) points from the >>> subobject to the parent page. In the above example, "street address" >>> really means "has street address" while in SIO it would be used like "is >>> street address of". >>> >>> The other difference is that subobjects work with both SQL and RDF >>> stores, are exported in RDF and are compatible with interfaces like >>> Special:Browse. >>> >>> >>> == Alternative Proposal == >>> >>> Instead of having a parser function that creates a subobject and assigns >>> it to a property as a value, one could also have a parser function that >>> only does the first thing and that *returns* a subobject for later use. >>> This would require some further changes but it might be more elegant. >>> >>> For example, a call like >>> >>> {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }} >>> >>> would just "create" such an object and return its name (e.g. >>> "Example_page#_someId"). Then one could use this name as a value to >>> other properties, e.g.: >>> >>> [[street address::{{#subobject: street name=Parks Road >>> | postcode=OX1 3QD >>> | city=Oxford >>> }}]] >>> >>> One advantage of this is that one could arbitrarily nest subobjects, >>> i.e. use subobjects as property values when declaring other subobjects >>> (SMW can already do this, just the input syntax does not support it). >>> Another advantage is that subobjects could (optionally) be named instead >>> of using the name generated by SMW now. For example, one could have >>> >>> {{#subobject:department_address >>> |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} >>> >>> to create a subobject called "Example page#department_address" which >>> could be used in other annotations on *any* page (this is already >>> possible with subobjects now, but since their names are generated by SMW >>> they might not be stable over time). In this case, it might be less >>> desirable to return the name of the subobject. >>> >>> Overall, this alternative approach would allow subobjects to be used as >>> first-class citizens of the SMW data space instead of viewing them as >>> auxiliary objects for encoding compound property values. >>> >>> >>> == Request for Comments == >>> >>> Feedback is welcome. The first question is which approach to subobjects >>> should eventually be used. The follow-up question is how the respective >>> parser function should be called. But there might also be completely >>> different comments and questions. >>> >>> >>> Cheers, >>> >>> Markus >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure contains a >>> definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and makes >>> sense of it. Business sense. IT sense. Common sense. >>> http://p.sf.net/sfu/splunk-d2dcopy1 >>> _______________________________________________ >>> Semediawiki-user mailing list >>> Sem...@li... >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>> >> >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> >> > |
From: Markus K. <ma...@se...> - 2011-10-07 14:07:07
|
On 06/10/11 16:09, CW Dillon wrote: > Jesse, > Ooh. I hadn't thought of that, with the recipe example. You're right. > ...there's always so much more that can be done! > > So, in addition to the "elegance" of option #2 is the flexibility of not > *needing* an interim object to get at it's data. If a data page is > desired/required, it can be created. OK. I'm convinced but, I'm only a > user. > > Markus, Which way are you leaning? Still toward #2. The only issue with this is that I will have to implement a bit more to make it work. Another nice aspect of #2 is that it completely voids the "property direction" discussion that we had regarding the fact that SIO internal objects point towards a page while Option #1 points away from it. With Option #2, there is no property required at all and one can create properties in either direction. Cheers, Markus > On Wed, Oct 5, 2011 at 3:16 PM, Jesse Wang <wj...@gm... > <mailto:wj...@gm...>> wrote: > > Clarence, I regard your distinction between "address" and "recipe" > as a practical modeling choice, it is case by case as you said. If > "500g of flour" or "a teaspoon of sugar" is used often enough, maybe > it makes sense to create a page for it, and you can add extra > properties to it such as calories... > > Back to the choices. I favor #2. As Markus said, it looks elegant, > and inline with existing SMW syntax. Moreover, it feels to be Object > Oriented, and you can parse it and treat it as an object so that you > can develop API, and further some kind of semantic object editor, to > handle it. The fact that it can be nested is also big, it opens > opportunities. Parsing and replacing text may also be easier. Say, > one day, you decide to change "Street Address" into "Physical > Address" then parsing and replacing existing properties should be > easier - does not have to go to all "#subobject" parser functions to > do it... > > Jesse > > On Mon, Oct 3, 2011 at 6:50 PM, CW Dillon <cwd...@gm... > <mailto:cwd...@gm...>> wrote: > > Markus, > Thanks for taking this on. I talked myself out of both solutions > three times, just in the span of writing a response. This is a > tough problem, I think. So, what niggles at me is whether it > is reasonable to argue for solution 1 or solution 2 based on > whether the "something" in the middle is real or abstract? > > I mean, you gave an example using an address but Yaron usually > talks about N-ary relations using a recipe analogy. An address > is a real thing that exists irregardless of where it's mentioned > in the wiki and the address has parts (which also have some sort > of relatedness in the real world). I think that in the case of > the address, it would be OK to make a wiki page for that > data--12 Downing Street is relevant even if the PM moves to 14 > Downing St, because it's still a real place. It's relevant > because some person or business occupies (or "Has") that address. > > Whereas the recipe example (quantity+ingredient) is more of an > adverb+verb combination and they are only relevant to each other > in the specific instance (and completely meaningless outside of > the recipe context). "500g of flour" would never deserve its own > wiki page. > > I think solution 1 suits the real case better but, would work > for both cases. Solution 2 really only works for the abstract > case. However, since the real case can be solved by making a > wiki page but the abstract case cannot, maybe solution 2 is the > preferable option. That way,people won't go around NOT making > wiki pages about things that really ought to have pages made > about them. > > -Clarence > > > > On Mon, Oct 3, 2011 at 5:02 AM, Markus Krötzsch > <ma...@se... > <mailto:ma...@se...>> wrote: > > Following up the discussions we had at SMWCon in Berlin, we > have now > implemented a new feature for "internal objects" in SMW. > This email > explains this feature and starts the discussion on some open > questions > for it to become stable. > > > == Goal == > > Allow SMW annotations to refer to objects that have their own > property-value pairs just like wiki pages, but that do not > actually have > an article in the wiki. This can be used to "group" > property-value pairs > given on one page without requiring new auxiliary pages to > be created. > It also integrates the main functionality of the Semantic > Internal > Objects (SIO) extension into SMW. > > > == Feature Overview: Current Prototype Implementation == > > SMW now has a new "subobject" feature. For example, you can > use the > parserfunction #subobject on some page "Example page" as > follows: > > {{#subobject:street address > | street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > | country=UK > }} > > This does the following: > > (A) create a new subobject called "Example page#_anInternalId", > (B) assign the property values for "street name", ..., > "country" to this > subobject, > (C) assign the subobject "Example page#_anInternalId" as a > property > value for "street address" to "Example page". > > You could have achieved a similar effect as follows: > > (A') create a new page called "my auxiliary page", > (B') edit this new page to contain the text: > > [[street name::Parks Road]] > [[postcode::OX1 3QD]] > [[city::Oxford]] > [[country::UK]] > > (C') edit the page "Example page" to contain the text: > > [[street address::my auxiliary page]] > > > The difference when using #subobject is that you do not > create a new > auxiliary page. Instead, a subobject of "Example page" is > created by > SMW. Also, the function #subobject does not display anything > unless an > error occurred that needs to be reported. > > Subobjects are named automatically by following the schema > "Parent page > name#_someInternalId". When subobjects are displayed to > users, they thus > appear like links to sections within their parent page. This > can happen, > e.g., subobjects might occur in query results (example > above: {{#ask: > [[postcode::OX1 3QD]] }}). Likewise, subobjects are also > addressed by > this name "Parent page name#_someInternalId" in all search > and export > interfaces in SMW. For example, one can view the data for > one particular > subobject in Special:Browse. > > In general, subobjects should work like normal pages in most SMW > interfaces. The goal of this naming is to avoid any clashes > with real > pages and with real sections in real pages while still > allowing the same > methods to be used. > > The feature can be tested in the current SVN version but it > is still > unstable and might change significantly (read on). > > > == Relation to Semantic Internal Objects == > > The feature is very similar to the SIO extension. The > difference is that > in SIO, the main property ("street address" above) points > from the > subobject to the parent page. In the above example, "street > address" > really means "has street address" while in SIO it would be > used like "is > street address of". > > The other difference is that subobjects work with both SQL > and RDF > stores, are exported in RDF and are compatible with > interfaces like > Special:Browse. > > > == Alternative Proposal == > > Instead of having a parser function that creates a subobject > and assigns > it to a property as a value, one could also have a parser > function that > only does the first thing and that *returns* a subobject for > later use. > This would require some further changes but it might be more > elegant. > > For example, a call like > > {{#subobject: street name=Parks Road | postcode=OX1 3QD| > city=Oxford }} > > would just "create" such an object and return its name (e.g. > "Example_page#_someId"). Then one could use this name as a > value to > other properties, e.g.: > > [[street address::{{#subobject: street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > }}]] > > One advantage of this is that one could arbitrarily nest > subobjects, > i.e. use subobjects as property values when declaring other > subobjects > (SMW can already do this, just the input syntax does not > support it). > Another advantage is that subobjects could (optionally) be > named instead > of using the name generated by SMW now. For example, one > could have > > {{#subobject:department_address > |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > to create a subobject called "Example > page#department_address" which > could be used in other annotations on *any* page (this is > already > possible with subobjects now, but since their names are > generated by SMW > they might not be stable over time). In this case, it might > be less > desirable to return the name of the subobject. > > Overall, this alternative approach would allow subobjects to > be used as > first-class citizens of the SMW data space instead of > viewing them as > auxiliary objects for encoding compound property values. > > > == Request for Comments == > > Feedback is welcome. The first question is which approach to > subobjects > should eventually be used. The follow-up question is how the > respective > parser function should be called. But there might also be > completely > different comments and questions. > > > Cheers, > > Markus > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT > infrastructure contains a > definitive record of customers, application performance, > security > threats, fraudulent activity and more. Splunk takes this > data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > <mailto:Sem...@li...> > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data > and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > <mailto:Sem...@li...> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > |
From: John M. <jmc...@hy...> - 2011-10-07 17:24:51
|
Under #2 scenario, if a template creates a subobject but never uses it in {{#set}} then what is the impact? Thanks |
From: Markus K. <ma...@se...> - 2011-10-13 06:14:35
|
On 07/10/11 19:21, John McClure wrote: > Under #2 scenario, if a template creates a subobject but never uses it in > {{#set}} then what is the impact? Then the subobject will be like a wikipage with the property values as specified. The subobject will just not have an incoming property from its parent page. This can occur, e.g., if subobjects are used as in the SIO extension with a property pointing *to* the parent page instead of away from it. Another possible use case are subobjects of subobjects which would also not have a direct relation to the parent page. Regards, Markus |
From: John M. <jmc...@hy...> - 2011-10-24 16:10:02
|
There is a difference though: wikipages are listed on special:allpages. If an object is the value of a page property, then it's listed on special:browse. If an object is not a value of any page property, then where is it listed? Maybe a pseudo namespace can contain these. -----Original Message----- From: Markus Krötzsch [mailto:ma...@se...] Sent: Wednesday, October 12, 2011 10:14 PM To: jmc...@hy... Cc: 'Semediawiki-user'; 'Semantic MediaWiki developers' Subject: Re: [SMW-devel] [Semediawiki-user] RFC Subobjects (aka "internal objects") in SMW On 07/10/11 19:21, John McClure wrote: > Under #2 scenario, if a template creates a subobject but never uses it in > {{#set}} then what is the impact? Then the subobject will be like a wikipage with the property values as specified. The subobject will just not have an incoming property from its parent page. This can occur, e.g., if subobjects are used as in the SIO extension with a property pointing *to* the parent page instead of away from it. Another possible use case are subobjects of subobjects which would also not have a direct relation to the parent page. Regards, Markus |
From: Markus K. <ma...@se...> - 2011-10-30 12:02:24
|
On 24/10/11 18:05, John McClure wrote: > There is a difference though: wikipages are listed on special:allpages. > If an object is the value of a page property, then it's listed on > special:browse. > If an object is not a value of any page property, then where is it listed? > Maybe a pseudo namespace can contain these. The use of a special property (currently called "has subobject") should solve this now. All subobjects now appear on Special:Browse and also on the property page Property:Has_subobject. Markus > > -----Original Message----- > From: Markus Krötzsch [mailto:ma...@se...] > Sent: Wednesday, October 12, 2011 10:14 PM > To: jmc...@hy... > Cc: 'Semediawiki-user'; 'Semantic MediaWiki developers' > Subject: Re: [SMW-devel] [Semediawiki-user] RFC Subobjects (aka > "internal objects") in SMW > > > On 07/10/11 19:21, John McClure wrote: >> Under #2 scenario, if a template creates a subobject but never uses it in >> {{#set}} then what is the impact? > > Then the subobject will be like a wikipage with the property values as > specified. The subobject will just not have an incoming property from > its parent page. > > This can occur, e.g., if subobjects are used as in the SIO extension > with a property pointing *to* the parent page instead of away from it. > Another possible use case are subobjects of subobjects which would also > not have a direct relation to the parent page. > > Regards, > > Markus > > |
From: John M. <jmc...@hy...> - 2011-10-30 16:57:48
|
great Markus. So all objects are always '#set' as a value of some property for a page at all times. Is this value removed from 'has subobject' when it is assigned to its actual property for the page, or when it is assigned as a property value for an object of the page? Thanks - john -----Original Message----- From: Markus Krötzsch [mailto:ma...@se...] Sent: Sunday, October 30, 2011 4:02 AM On 24/10/11 18:05, John McClure wrote: > There is a difference though: wikipages are listed on special:allpages. > If an object is the value of a page property, then it's listed on > special:browse. > If an object is not a value of any page property, then where is it listed? > Maybe a pseudo namespace can contain these. The use of a special property (currently called "has subobject") should solve this now. All subobjects now appear on Special:Browse and also on the property page Property:Has_subobject. Markus |
From: Markus K. <ma...@se...> - 2011-10-30 21:03:36
|
On 30/10/11 17:53, John McClure wrote: > great Markus. So all objects are always '#set' as a value of some property > for a page at all times. Is this value removed from 'has subobject' when it > is assigned to its actual property for the page, or when it is assigned as a > property value for an object of the page? No, it is always there. Regards, Markus > > -----Original Message----- > From: Markus Krötzsch [mailto:ma...@se...] > Sent: Sunday, October 30, 2011 4:02 AM > > On 24/10/11 18:05, John McClure wrote: >> There is a difference though: wikipages are listed on special:allpages. >> If an object is the value of a page property, then it's listed on >> special:browse. >> If an object is not a value of any page property, then where is it listed? >> Maybe a pseudo namespace can contain these. > > The use of a special property (currently called "has subobject") should > solve this now. All subobjects now appear on Special:Browse and also on > the property page Property:Has_subobject. > > Markus > > |
From: Gregor H. <g.m...@gm...> - 2011-10-05 14:03:24
|
>> Would these subobjects interfere at some stage with the support of >> multi-value properties or replace them? Or will they remain an additional >> feature like the SIOs? > > Multi-valued properties in SMW 1.6 are already a special kind of > subobject. Both kinds of subobject work well together (i.e., one can > have Type:Record properties in subobjects). It is not planned to drop > record support. Sorry to ask back: you mentioned the reversal of direction compared with SIO. At least for the second case of the subobject returning its ID I am not clear how to have tabular subobjects (i.e. many subobjects of the same type). The example of a singular adress is clear. Not clear is: a literature page (= wikipage) with a hypothetical repeatable subobject "figure" containing of the tupel "fig_number", "printed_page", and "caption". Can this be done with a subobject? Gregor |
From: Markus K. <ma...@se...> - 2011-10-07 14:54:14
|
On 05/10/11 15:02, Gregor Hagedorn wrote: >>> Would these subobjects interfere at some stage with the support of >>> multi-value properties or replace them? Or will they remain an additional >>> feature like the SIOs? >> >> Multi-valued properties in SMW 1.6 are already a special kind of >> subobject. Both kinds of subobject work well together (i.e., one can >> have Type:Record properties in subobjects). It is not planned to drop >> record support. > > Sorry to ask back: you mentioned the reversal of direction compared > with SIO. At least for the second case of the subobject returning its > ID I am not clear how to have tabular subobjects (i.e. many subobjects > of the same type). The example of a singular adress is clear. Not > clear is: a literature page (= wikipage) with a hypothetical > repeatable subobject "figure" containing of the tupel "fig_number", > "printed_page", and "caption". Can this be done with a subobject? Subobjects as such do not have a type. They are defined by their content which is given by property-value pairs. So if you need many "Figures" on one page, you can simply create many subobjects with the required property values. But maybe you have been asking the opposite question? If you have *one* subobject that you want to use as a value to *many* properies, then just using the #subobject function in one property assignment would not work. To solve this, we would allow subobjects to have "names" to be assigned to them. So you could have a subobject "figure_1" and this would have a stable ID "pagename#figure_1" that can be used in as many places as you like. Markus |
From: Yury K. <kat...@gm...> - 2011-10-12 22:47:58
|
Hello Markus, First of all, your alternative proposal looks much better than the original one because of more flexibility. And praise you for the great solution of optional naming - I hope it will be possible to implement it! What about RDF export and Import vocabulary features? I have really two questions concerning both those features: == RDFExport+RDF store question== As far I as I can see subobjects should be turned to the blank nodes, shouldn't they? == Import vocabulary question == Is it possible to map the subobject to RDF class? That can be extremely useful even in simple vocabularies like FOAF. Here is an example: we have the wiki-page of Yury who has an online account in two social networks: Facebook and Vkontakte. ===Example=== It's pretty easy to describe this fact with subobjects: ##### PAGE STARTS######### Yury has [[has account::{{#subobject: service=http://facebook.com accountname=ganqqwerty}} |facebook account]], [[has account:: {{#subobject: service=vkontakte.ru accountname=katkov}} |Vkontakte.ru account]] #####PAGE ENDS######### ===RDF Export=== If I map has account to foaf:account, map service to uring rdf export we will get the following (simplified) :Yury_id_in_wiki foaf:account :Yury_id_in_wiki#tmpnum1 . :Yury_id_in_wiki#tmpnum1 foaf:accountServiceHomepage <http://facebook.com> :Yury_id_in_wiki#tmpnum1 foaf:accountName "ganqqwerty" === Problem === The problem is that the property foaf:account has range foaf:OnlineAccount. Our RDF export now is a little bit incomplete. ===Proposal=== Make it possible to assign some kind of type to the subobject and map those types to RDFS or OWL classes. I honestly don't know how this can be done - probably with the special attribute "type" or "category". The typing can be needed now only in case of RDF export. If I have a wiki with thousands of subobjects it would always be nice to see what kind of subobjects are there. Anyway the subobject feature will help me to tie together a bundle of properties in Semantic Social Profile, for example Name of the country of living, Name of the city of living, Street, house number as well as Geographic coordinates of the place where the user lives. Sorry if was late fo the discussion, Yury On Mon, Oct 3, 2011 at 1:02 PM, Markus Krötzsch <ma...@se...> wrote: > > Following up the discussions we had at SMWCon in Berlin, we have now > implemented a new feature for "internal objects" in SMW. This email > explains this feature and starts the discussion on some open questions > for it to become stable. > > > == Goal == > > Allow SMW annotations to refer to objects that have their own > property-value pairs just like wiki pages, but that do not actually have > an article in the wiki. This can be used to "group" property-value pairs > given on one page without requiring new auxiliary pages to be created. > It also integrates the main functionality of the Semantic Internal > Objects (SIO) extension into SMW. > > > == Feature Overview: Current Prototype Implementation == > > SMW now has a new "subobject" feature. For example, you can use the > parserfunction #subobject on some page "Example page" as follows: > > {{#subobject:street address > | street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > | country=UK > }} > > This does the following: > > (A) create a new subobject called "Example page#_anInternalId", > (B) assign the property values for "street name", ..., "country" to this > subobject, > (C) assign the subobject "Example page#_anInternalId" as a property > value for "street address" to "Example page". > > You could have achieved a similar effect as follows: > > (A') create a new page called "my auxiliary page", > (B') edit this new page to contain the text: > > [[street name::Parks Road]] > [[postcode::OX1 3QD]] > [[city::Oxford]] > [[country::UK]] > > (C') edit the page "Example page" to contain the text: > > [[street address::my auxiliary page]] > > > The difference when using #subobject is that you do not create a new > auxiliary page. Instead, a subobject of "Example page" is created by > SMW. Also, the function #subobject does not display anything unless an > error occurred that needs to be reported. > > Subobjects are named automatically by following the schema "Parent page > name#_someInternalId". When subobjects are displayed to users, they thus > appear like links to sections within their parent page. This can happen, > e.g., subobjects might occur in query results (example above: {{#ask: > [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by > this name "Parent page name#_someInternalId" in all search and export > interfaces in SMW. For example, one can view the data for one particular > subobject in Special:Browse. > > In general, subobjects should work like normal pages in most SMW > interfaces. The goal of this naming is to avoid any clashes with real > pages and with real sections in real pages while still allowing the same > methods to be used. > > The feature can be tested in the current SVN version but it is still > unstable and might change significantly (read on). > > > == Relation to Semantic Internal Objects == > > The feature is very similar to the SIO extension. The difference is that > in SIO, the main property ("street address" above) points from the > subobject to the parent page. In the above example, "street address" > really means "has street address" while in SIO it would be used like "is > street address of". > > The other difference is that subobjects work with both SQL and RDF > stores, are exported in RDF and are compatible with interfaces like > Special:Browse. > > > == Alternative Proposal == > > Instead of having a parser function that creates a subobject and assigns > it to a property as a value, one could also have a parser function that > only does the first thing and that *returns* a subobject for later use. > This would require some further changes but it might be more elegant. > > For example, a call like > > {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > would just "create" such an object and return its name (e.g. > "Example_page#_someId"). Then one could use this name as a value to > other properties, e.g.: > > [[street address::{{#subobject: street name=Parks Road > | postcode=OX1 3QD > | city=Oxford > }}]] > > One advantage of this is that one could arbitrarily nest subobjects, > i.e. use subobjects as property values when declaring other subobjects > (SMW can already do this, just the input syntax does not support it). > Another advantage is that subobjects could (optionally) be named instead > of using the name generated by SMW now. For example, one could have > > {{#subobject:department_address > |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > to create a subobject called "Example page#department_address" which > could be used in other annotations on *any* page (this is already > possible with subobjects now, but since their names are generated by SMW > they might not be stable over time). In this case, it might be less > desirable to return the name of the subobject. > > Overall, this alternative approach would allow subobjects to be used as > first-class citizens of the SMW data space instead of viewing them as > auxiliary objects for encoding compound property values. > > > == Request for Comments == > > Feedback is welcome. The first question is which approach to subobjects > should eventually be used. The follow-up question is how the respective > parser function should be called. But there might also be completely > different comments and questions. > > > Cheers, > > Markus > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Yury V. Katkov WikiVote! llc |
From: Yury K. <kat...@gm...> - 2011-10-23 09:36:37
|
Was I talkling gibberish or was the RDF export question too hard? :) On Thu, Oct 13, 2011 at 2:47 AM, Yury Katkov <kat...@gm...> wrote: > Hello Markus, > First of all, your alternative proposal looks much better than the > original one because of more flexibility. And praise you for the great > solution of optional naming - I hope it will be possible to implement > it! > > What about RDF export and Import vocabulary features? I have really > two questions concerning both those features: > > == RDFExport+RDF store question== > > As far I as I can see subobjects should be turned to the blank nodes, > shouldn't they? > > == Import vocabulary question == > > Is it possible to map the subobject to RDF class? That can be > extremely useful even in simple vocabularies like FOAF. > Here is an example: we have the wiki-page of Yury who has an online > account in two social networks: Facebook and Vkontakte. > > ===Example=== > It's pretty easy to describe this fact with subobjects: > ##### PAGE STARTS######### > Yury has [[has account::{{#subobject: > service=http://facebook.com > accountname=ganqqwerty}} > |facebook account]], > [[has account:: {{#subobject: > service=vkontakte.ru > accountname=katkov}} > |Vkontakte.ru account]] > #####PAGE ENDS######### > ===RDF Export=== > If I map has account to foaf:account, map service to uring rdf export > we will get the following (simplified) > :Yury_id_in_wiki foaf:account > :Yury_id_in_wiki#tmpnum1 . > :Yury_id_in_wiki#tmpnum1 foaf:accountServiceHomepage <http://facebook.com > > > :Yury_id_in_wiki#tmpnum1 foaf:accountName "ganqqwerty" > === Problem === > The problem is that the property foaf:account has range > foaf:OnlineAccount. Our RDF export now is a little bit incomplete. > > ===Proposal=== > > Make it possible to assign some kind of type to the subobject and map > those types to RDFS or OWL classes. I honestly don't know how this can > be done - probably with the special attribute "type" or "category". > > The typing can be needed now only in case of RDF export. If I have a > wiki with thousands of subobjects it would always be nice to see what > kind of subobjects are there. > > > Anyway the subobject feature will help me to tie together a bundle of > properties in Semantic Social Profile, for example Name of the country > of living, Name of the city of living, Street, house number as well as > Geographic coordinates of the place where the user lives. > > Sorry if was late fo the discussion, > Yury > > On Mon, Oct 3, 2011 at 1:02 PM, Markus Krötzsch > <ma...@se...> wrote: > > > > Following up the discussions we had at SMWCon in Berlin, we have now > > implemented a new feature for "internal objects" in SMW. This email > > explains this feature and starts the discussion on some open questions > > for it to become stable. > > > > > > == Goal == > > > > Allow SMW annotations to refer to objects that have their own > > property-value pairs just like wiki pages, but that do not actually have > > an article in the wiki. This can be used to "group" property-value pairs > > given on one page without requiring new auxiliary pages to be created. > > It also integrates the main functionality of the Semantic Internal > > Objects (SIO) extension into SMW. > > > > > > == Feature Overview: Current Prototype Implementation == > > > > SMW now has a new "subobject" feature. For example, you can use the > > parserfunction #subobject on some page "Example page" as follows: > > > > {{#subobject:street address > > | street name=Parks Road > > | postcode=OX1 3QD > > | city=Oxford > > | country=UK > > }} > > > > This does the following: > > > > (A) create a new subobject called "Example page#_anInternalId", > > (B) assign the property values for "street name", ..., "country" to this > > subobject, > > (C) assign the subobject "Example page#_anInternalId" as a property > > value for "street address" to "Example page". > > > > You could have achieved a similar effect as follows: > > > > (A') create a new page called "my auxiliary page", > > (B') edit this new page to contain the text: > > > > [[street name::Parks Road]] > > [[postcode::OX1 3QD]] > > [[city::Oxford]] > > [[country::UK]] > > > > (C') edit the page "Example page" to contain the text: > > > > [[street address::my auxiliary page]] > > > > > > The difference when using #subobject is that you do not create a new > > auxiliary page. Instead, a subobject of "Example page" is created by > > SMW. Also, the function #subobject does not display anything unless an > > error occurred that needs to be reported. > > > > Subobjects are named automatically by following the schema "Parent page > > name#_someInternalId". When subobjects are displayed to users, they thus > > appear like links to sections within their parent page. This can happen, > > e.g., subobjects might occur in query results (example above: {{#ask: > > [[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by > > this name "Parent page name#_someInternalId" in all search and export > > interfaces in SMW. For example, one can view the data for one particular > > subobject in Special:Browse. > > > > In general, subobjects should work like normal pages in most SMW > > interfaces. The goal of this naming is to avoid any clashes with real > > pages and with real sections in real pages while still allowing the same > > methods to be used. > > > > The feature can be tested in the current SVN version but it is still > > unstable and might change significantly (read on). > > > > > > == Relation to Semantic Internal Objects == > > > > The feature is very similar to the SIO extension. The difference is that > > in SIO, the main property ("street address" above) points from the > > subobject to the parent page. In the above example, "street address" > > really means "has street address" while in SIO it would be used like "is > > street address of". > > > > The other difference is that subobjects work with both SQL and RDF > > stores, are exported in RDF and are compatible with interfaces like > > Special:Browse. > > > > > > == Alternative Proposal == > > > > Instead of having a parser function that creates a subobject and assigns > > it to a property as a value, one could also have a parser function that > > only does the first thing and that *returns* a subobject for later use. > > This would require some further changes but it might be more elegant. > > > > For example, a call like > > > > {{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > > > would just "create" such an object and return its name (e.g. > > "Example_page#_someId"). Then one could use this name as a value to > > other properties, e.g.: > > > > [[street address::{{#subobject: street name=Parks Road > > | postcode=OX1 3QD > > | city=Oxford > > }}]] > > > > One advantage of this is that one could arbitrarily nest subobjects, > > i.e. use subobjects as property values when declaring other subobjects > > (SMW can already do this, just the input syntax does not support it). > > Another advantage is that subobjects could (optionally) be named instead > > of using the name generated by SMW now. For example, one could have > > > > {{#subobject:department_address > > |street name=Parks Road | postcode=OX1 3QD| city=Oxford }} > > > > to create a subobject called "Example page#department_address" which > > could be used in other annotations on *any* page (this is already > > possible with subobjects now, but since their names are generated by SMW > > they might not be stable over time). In this case, it might be less > > desirable to return the name of the subobject. > > > > Overall, this alternative approach would allow subobjects to be used as > > first-class citizens of the SMW data space instead of viewing them as > > auxiliary objects for encoding compound property values. > > > > > > == Request for Comments == > > > > Feedback is welcome. The first question is which approach to subobjects > > should eventually be used. The follow-up question is how the respective > > parser function should be called. But there might also be completely > > different comments and questions. > > > > > > Cheers, > > > > Markus > > > > > > > ------------------------------------------------------------------------------ > > All the data continuously generated in your IT infrastructure contains a > > definitive record of customers, application performance, security > > threats, fraudulent activity and more. Splunk takes this data and makes > > sense of it. Business sense. IT sense. Common sense. > > http://p.sf.net/sfu/splunk-d2dcopy1 > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > Yury V. Katkov > WikiVote! llc > -- Yury V. Katkov WikiVote! llc |