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
