On 03/10/11 22:58, John McClure wrote:
> Markus,
> #subobject is great to hear about, though I look at
> http://semantic-mediawiki.org/wiki/Special:Version and I don't see it yet
> listed as a parser function; is there a schedule in mind for public testing?
> And I'm not understanding how records are still useful given #subobject's
> availability -- are records to become a backwards-compatibility thing?
Records are an independent feature that is not under discussion right
now. The fact that records largely are based on the same internal
mechanisms as subobects reduces the cost of keeping them in the code.
>
> Anyway to give you a feel for my own perspective, I'm working to allow users
> via forms to associate a page with attributes possibly annotated with, for
> instance, provenance info. I store these attribute annotations in Dublin
> Core properties within an attribute object attached to the page. Of course
> users are not constrained at the same time from annotating a page's content
> directly. I then had a choice between implementing the attribute objects as
> records or as sio's - I chose SIO primarily because it preserves basic #ask
> syntax, thank you Yaron, which can be used in compound queries.
>
> Your note says to me though that you're reimplementing records to be
> amenable to basic ask syntax (plus other goodies you mention).
This should already be the case. Records are stored like subobjects with
a fixed list of properties. So they can be queried in the same way too.
> It'd help my
> understanding alot to contrast use cases for various queries that retrieve
>
> * all subobjects in the wiki with a particular property&or value
There is no distinction between subobjects and normal pages. You can
find all things that have a particular property or property value but
you cannot filter this to only get subobjects (and no pages that match
the query).
> * all pages in the wiki with a subobject having a particular property&or
> value
> * the container subobject for a given nested subobject
> * the container page for a given subobject or a given nested subobject
These are all easy to do, just as one would do the same queries for
pages. Again, there is no distinction between pages and subobjects, so
there is no difference between the last two queries. Also note that,
with the currently implemented parserfunction, you cannot create nested
subobjects for lack of syntax.
>
> Other notes:
> # re:Browse
> * can subobjects be shown (in a subtable) on special:browse/Example_page,
> not separate browse pages for each subobject
Possible, but this would need a new interface. Special:Browse is not
suitable for displaying nested property values (otherwise, one could do
a similar thing for arbitrary pages, not just for subobjects).
>
> # re:#subobject syntax
> * I definitely prefer {{#set:pageprop={{#subobject:
> objname|prop1=val1|...}}}}
Yes, I also find this more logical.
> * I'd like to store a formatting template name in the subobject too (see
> below), eg
> {{#set:pageprop={{#subobject: objname|templatename|prop1=val1|...}}}}
SMW does not support this since one can already achieve the same thing
by using a formatting template instead of #subobject, and use #subobject
within the template. We would like to leave formatting to MediaWiki and
keep the task of SMW to be data management.
>
> # re:subobject annotations
> * I much would like the object to preserve implicit formatting provided by a
> modified syntax for instance:
> [[[address::[[bldgnbr::123]] [[street name::Parks Road]], [[city::Oxford]]
> [[postcode::OX1 3QD]] [[country::UK]] ]]]
> which would be output by {{#show:{{FULLPAGENAME}}|?address=}}
This is not possible with SMW unless one would change the data model in
a quite fundamental fashion. Data in SMW is independent of formatting
and of the order in which it was given on a page. This basic data model
is the same for subobjects. Also, the above syntax with nested [[ ]]
does not work in SMW since we are lacking an efficient way to parse this
(there is a switch to enable this but this does not work with longer
pages unless the Perl regexp library in PHP became a lot more efficient
since I last tested it).
However, you can store formatted strings of wikitext like "address" in
your above example by using a property of Type:Text in #set. Using a
template, one could therefore store both the formatted address and the
subobject that is based on this data.
Another solution would be to create pages with the formatted content and
to transclude them whenever the original formatting is desired.
>
> # re: ask templates
> * can the param value for a subobject property optionally be its name OR its
> formatted OR unformatted content
I don't think I understand what you mean here. But maybe this is already
moot given that formatting is not part of the stored data?
>
> Bottom line, it's really good to see SIO functionality moved into core SMW.
Yes, I have been convinced that many users want this.
Regards,
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
