Hi,
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?
-Yaron
On Tue, Apr 5, 2011 at 4:06 PM, John McClure <jmccl...@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 with various related efforts but hesitate to do so without hearing
> feedback from developers more kowledgeable than I am. I've been reviewing
> the smw codebase with my thoughts in mind and am beginning to conclude that
> it can be done relatively painlessly.
>
> In summary, my belief is that specification of logical resource properties
> should be separable from those concerned with its physical
> presentation. Preventing this however is that SMW requires that all
> properties of a resource be decalred in its page; this page being one
> inventoried in a namespace registered via $smwgNamespacesWithSemanticLinks.
> In fact I've noticed all namespaces so registered are unfailngly
> {{SUBJECTSPACE}}s -- none are {{TALKSPACE}}s, and that this fact presents
> exploitable opportunities to us all. (Indeed many might seriously question a
> semantic wiki's design that registers *any* {{TALKSPACE}} as a "semantic"
> namespace).
>
> So what I propose seems 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 as being 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 is also 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 *about *its {{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 to implmenting a "Trusted
> Web", the pinnacle of the TBL pyramid.
>
> Finally, this change addresses a potential operational problem in SMW's
> design -- which interweaves resource presentation with its logical data
> model -- mandating the same persons are to be 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 proposal as I incorporate Liquid Threads in my wiki, so it's my
> direction that both sets of information -- logical data model and discussion
> threads -- are available whenever one navigates to a {{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 about overall
> wiki performance, 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.
>
> Thanks.
>
>
>
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
