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 <mar...@semantic-mediawiki.org> 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 > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel ------------------------------------------------------------------------------ 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 Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel