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 <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> 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> 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
>>> 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
>>
>>
>
------------------------------------------------------------------------------
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
