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 <wjxhome@...
> <mailto:wjxhome@...>> 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 <cwdillon@...
> <mailto:cwdillon@...>> 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
> <markus@...
> <mailto:markus@...>> 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-user@...
> <mailto:Semediawiki-user@...>
> 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@...
> <mailto:Semediawiki-devel@...>
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
>
|