Updates on the "subobject" feature. The following changes have now been
implemented and committed to SVN.
== Parser function #subobject ==
The new parser function #subobject can be used to create *named*
subobjects. Example:
{{#subobject:My office address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
}}
creates a new subobject with four property values. If this is done on a
page called "Testpage" then the subobject is named
"Testpage#My_office_address" and it can be used under that name
everywhere in the wiki. Example:
[[has office address::Testpage#My_office_address]]
You can use space " " instead of underscore "_" as they are equivalent
in fragments (in MediaWiki) and in subobject names (in SMW). However,
note that fragment names are strictly case sensitive, even in the fist
letter. So "my office address" is not the same as "My office address".
To have a property from the subobject to the parent page (like in the
SIO extension) simply add such a property to the data. Example:
{{#subobject:My office address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
| is address of=Markus Kroetzsch
}}
on the page "Markus Kroetzsch".
The #subobject parser function is completely silent and returns no text
unless errors occur. If errors happen, then they are shown in the place
where the parser function is used.
== Fragment support for wiki page values ==
As indicated above, all wiki page property values can now have
fragments. They will be stored faithfully and be part of the meaning of
a value. Different fragment names encode different values.
You can also use the MediaWiki shortcut for fragments of the page you
are one. Example:
[[has office address::#My office address]]
on the page "Testpage" has the same meaning as [[has office
address::Testpage#My office address]]. This makes it easier to link to
subobjects too.
== Interaction with subobjects ==
Subobjects work like pages in all interfaces (they are represented in
the same datastructure internally, so all existing code will work with
them if it works with pages now).
All subobjects of a page that are created with #subobject are assigned
to the new predefined property "Has subobject". This can be used to
query for all subobjects and to show them on pages like Special:Browse
even if they are not otherwise linked to anything.
Cheers,
Markus
P.S. I have also adjusted the display of page names in SMW in general as
part of the inclusion of subobjects. This may affect some displays,
especially if the change was not propagated to all places in SMW. I will
send another email to the devleoper list to explain the details to other
devs. Let me know if you discover any display problems with page names.
On 03/10/11 10:02, Markus Krötzsch 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
>
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
