semediawiki-devel
|
From: Petr Andreyev <gulliput@gm...> - 2008-01-19 17:43:48
Attachments:
Message as HTML
|
Hi! I would like to add a new tab based on semantic properties of the page (I am doing this from my own extension). The question is what's the best way to do it? The problem gets more complicated for an older revision of a page. As I can see from the SemanticMediawiki database structure only the properties of the last revision are stored in the DB. What are other ways to access properties? The Factbox class does the scan of all properties for the currently displayed page (any revision), so in principle this could be done by means of some hacking. But may be there are some decent ways to do it? So once again, I want to do something (display or not display an extra tab) on the page for older revision of articles based on semantic properties of that older revision. How can I access those properties for the older revision from my extension (from a hook function)? Any hint will be greatly appreciated! Thanks! Petr |
|
From: Markus <mak@ai...> - 2008-01-21 10:35:59
Attachments:
application/pgp-signature
|
On Samstag, 19. Januar 2008, Petr Andreyev wrote: > Hi! > > I would like to add a new tab based on semantic properties of the page (I > am doing this from my own extension). The question is what's the best way > to do it? > The problem gets more complicated for an older revision of a page. > > As I can see from the SemanticMediawiki database structure only the > properties of the last revision are stored in the DB. > > What are other ways to access properties? > > The Factbox class does the scan of all properties for the currently > displayed page (any revision), so in principle this could be done by means > of some hacking. > But may be there are some decent ways to do it? > > So once again, I want to do something (display or not display an extra ta= b) > on the page for older revision of articles based on semantic properties of > that older revision. > How can I access those properties for the older revision from my extension > (from a hook function)? > > Any hint will be greatly appreciated! During parsing, SMW will store all semantic data contained in an articles t= ext=20 (whether revision or current) within the SMWFactbox::$semdata which is an=20 object of class SMWSemanticData. You could access that object *after parsin= g*=20 to extract data directly. I do not see another way of solving that. Some=20 problems may still occur, since SMW depends on non-local data (e.g. datatyp= es=20 of properties) that will influence parsing, but that is not versioned. I=20 think MW has some similar issues with old revisions using current versions = of=20 templates. Regards, Markus > > Thanks! > Petr =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 mak@... www http://korrekt.org |
|
From: Petr Andreyev <gulliput@gm...> - 2008-01-21 10:57:55
Attachments:
Message as HTML
|
Hi Markus, During parsing, SMW will store all semantic data contained in an articles > text > (whether revision or current) within the SMWFactbox::$semdata which is an > object of class SMWSemanticData. You could access that object *after > parsing* > to extract data directly. I do not see another way of solving that. Some > problems may still occur, since SMW depends on non-local data (e.g. > datatypes > of properties) that will influence parsing, but that is not versioned. I > think MW has some similar issues with old revisions using current versions > of > templates. > Thanks for the hint. It can solve the issue. But what I would expect from SMW (a kind of natural functionality) is being able to work with semantic properties of any given article in PHP code. This would mean in particular (as a basic level) having access to the props of the currently displayed article (any revision). Why I find this functionality natural? SMW extends articles with semantic properties. So, for an object representing article there should be methods available for dealing with its semantic properties. So, it's natural just from the point of view of OO. I think implementing this mechanism would open many new applications of SMW. With best regards, Petr |
|
From: Markus <mak@ai...> - 2008-01-21 13:55:35
Attachments:
application/pgp-signature
|
On Montag, 21. Januar 2008, Petr Andreyev wrote: > Hi Markus, > > During parsing, SMW will store all semantic data contained in an articles > > > text > > (whether revision or current) within the SMWFactbox::$semdata which is = an > > object of class SMWSemanticData. You could access that object *after > > parsing* > > to extract data directly. I do not see another way of solving that. Some > > problems may still occur, since SMW depends on non-local data (e.g. > > datatypes > > of properties) that will influence parsing, but that is not versioned. I > > think MW has some similar issues with old revisions using current > > versions of > > templates. > > Thanks for the hint. > > It can solve the issue. > But what I would expect from SMW (a kind of natural functionality) is bei= ng > able to work with semantic properties of any given article in PHP code. > This would mean in particular (as a basic level) having access to the pro= ps > of the currently displayed article (any revision). > > Why I find this functionality natural? SMW extends articles with semantic > properties. So, for an object representing article there should be methods > available for dealing with its semantic properties. So, it's natural just > from the point of view of OO. > > I think implementing this mechanism would open many new applications of > SMW. Yes, I understand. Basically the idea would be to have OO-based access to t= he=20 semantic storage. I think the next step to a better interface is to=20 completely remove MW objects from the storage interface: we already use=20 SMWDataValue for all annotation objects (including pages), we now should al= so=20 use it everywhere for subjects. Also, there should be a new container=20 (SMWDataValue?) for properties, so they are not represented by Titles. But all this requires some time ... if you have some to spare, you can prop= ose=20 interfaces for what you have in mind, but I will not have major coding time= =20 within the next weeks (e.g. documentation is still missing). Best regards, Markus =2D-=20 Markus Kr=F6tzsch Institut AIFB, Universit=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 mak@... www http://korrekt.org |