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 <wjxh...@gmail.com > <mailto:wjxh...@gmail.com>> 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 <cwdil...@gmail.com > <mailto:cwdil...@gmail.com>> 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 > <mailto:Semediawiki-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
