If I understand this correctly, you basically just want to be able to put semantic annotations on talk pages, and have those annotations apply to the corresponding main page. (There's also a related thing where red links to a page should point to its talk page instead.)

That sounds like a hack to me - after all, talk pages are intended only for discussions. But maybe I'm missing something: can you give an example of when this would come in handy?


On Tue, Apr 5, 2011 at 4:06 PM, John McClure <jmcclure@hypergrove.com> wrote:
Dear all,
SMW is a terrific package, and is becoming more so with each passing release. I'd like to pose a design change that I think will more closely align SMW withvariousrelated effortsbut hesitate to do so without hearing feedback from developers more kowledgeable than I am. I've been reviewing the smw codebase withmythoughts in mindandam beginning to conclude that it can be done relatively painlessly.
In summary, mybelief is that specification of logical resource properties should be separable fromthose concerned with its physical presentation.Preventing this however is thatSMW requires that all properties of a resource bedecalred initspage; this pagebeing one inventoried in anamespace registered via $smwgNamespacesWithSemanticLinks. In factI've noticed allnamespaces so registered are unfailngly {{SUBJECTSPACE}}s -- none are {{TALKSPACE}}s, and that this fact presents exploitable opportunities to us all. (Indeed many might seriously questiona semantic wiki's design thatregisters any {{TALKSPACE}} as a "semantic" namespace).
So whatIproposeseems simple: all {{#set:}} expressions located on a page within a non-semantic {{TALKSPACE}} are to be recorded for the page's {{SUBJECTPAGENAME}} equivalent, whenever the {{SUBJECTSPACE}} has been registered asbeing semantic. This new capability does not replace any current functionality whatsoever, such as annotations within the content of the presentation for a resource. Nor does this capability allow for statements about a 'foreign' subject {{PAGENAME}}. Rather, this change is consistent with normal wiki handling for a page's {{TALKPAGENAME}}, eg when a {{SUBJECTPAGENAME}} is moved or deleted, then its {{TALKPAGENAME}} is similarly moved or deleted -- mediawiki already treats the two pages as near-inseparable aspects of a single 'subject'.
This change isalso consistent with the OWL community's posture with regard to spo statements: all should reference rdf:about, never rdf:ID; all statements in a {{TALKSPACE}} therefore quite naturally lend themselves to being aboutits{{SUBJECTSPACE}}resource. Furthermore this approach provides a way forward to characterize multiple 'talk' statements about a resource each with provenance & contextual metadata -- in other words, providing the foundation for algorithms related toimplmenting a"Trusted Web", the pinnacle of theTBL pyramid.
Finally, this change addresses a potential operationalproblemin SMW's design -- which interweaves resource presentation with its logical data model -- mandating the samepersons are tobe responsible for both sets of information. But this is also to say that presentation remains a critical function! Meaning that, for instance, redlinks should only exist for pages for which there is neither a {{SUBJECTSPACE}} nor a {{TALKSPACE}} page, ie a bluelink is generated first to a {{SUBJECTPAGENAME}} and, if not existing, then to a {{TALKPAGENAME}} if it does exist. And that all SF-managed redlinks are to be routed to the {{TALKPAGENAME}} form not the {{SUBJECTPAGENAME}} form.
I make this proposalas Iincorporate Liquid Threadsin my wiki, so it's my direction that both sets of information -- logical data model and discussion threads -- are available whenever one navigates toa {{TALKPAGENAME}}. When one edits a {{SUBJECTSPACE}} page,its form is concerned with presentation parameters,with a link to the form for its {{TALKPAGENAME}} ie the logical data model for the subject-page, and vice-versa. And thinking aboutoverall wikiperformance, this approach could actually *improve* matters for many wikis whenever wikipage text and presentation-related properties change more often than the resource's underlying logical properties.
To make this all work, I think mostly what I need is for the {{#set:}} function on a {{TALKPAGENAME}} to be applicable to its subject page. It'd be great to hear that your thinking is also along these lines and if not, that this isn't a crackpot idea.

Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
Semediawiki-devel mailing list

WikiWorks MediaWiki Consulting http://wikiworks.com