On 03/10/11 11:48, zehetner wrote:
> 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?
Multi-valued properties in SMW 1.6 are already a special kind of
subobject. Both kinds of subobject work well together (i.e., one can
have Type:Record properties in subobjects). It is not planned to drop
record support.
Markus
> 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
