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