Markus,
On page "Test" I defined several subobjects:
{{ #subobject: Point 1 | Name = Point A | Coords = ... | Descr = ... }}
{{ #subobject: Point 2 | Name = Point B | Coords = ... | Descr = ... }}
{{ #subobject: Point 3 | Name = Point C | Coords = ... | Descr = ... }}
I want to display a table of points:
Name Coords Descr
Point A ... ...
Point B ... ...
Point C ... ...
I think #ask with tabular format should work. However, I failed to
create such a request:
{{ #ask: ??? what ??? | ?Name | ?Coords | ?Descr }}
I faced this problem few month ago -- SMW cannot select pages by /name/.
That time I wanted to select pages which name start with specific
string, but failed to construct a query. (I used SubPageList extension
to workaround the problem.) This time I want to select subobject which
names start with specific string (e. g. "Test#Point "), and again,
cannot manage it. I think I can implement a workaround:
{{ #subobject: Point 1 | Parent = {{{ FULLPAGENAME }} | Type = Point |
Name = Point A | Coords = ... | Descr = ... }}
{{ #subobject: Point 2 | Parent = {{{ FULLPAGENAME }} | Type = Point |
Name = Point B | Coords = ... | Descr = ... }}
{{ #subobject: Point 3 | Parent = {{{ FULLPAGENAME }} | Type = Point |
Name = Point C | Coords = ... | Descr = ... }}
So query will be something like
{{ #ask: [[Parent::Test]] [[Type::Point]] | ?Name | ?Coords | ?Descr }}
But may be it's time to implement querying pages by name?
If I am wrong ans SMW can select pages by name, please show me the way.
Van.
On Sat, 2011-10-29 at 22:46 +0100, Markus Krötzsch wrote:
> 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@...
> > 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-user mailing list
> Semediawiki-user@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
|