I can see a use for this sort of thing with any automated annotation
application.
It would be nice to have a way to store complex, arcane annotations without
overloading the wiki page itself.
It doesn't have to be in the talk page, maybe a separate name space
altogether, but being able to extend annotations of one page to the same
page in a different name space could have some benefits.
A practical example is the Semantic History extension :
http://www.mediawiki.org/wiki/Extension:SemanticHistory
Having these annotations in a separate namespace and still related to the
original page would help.
- Laurent
On Tue, Apr 5, 2011 at 6:19 PM, John McClure <jmccl...@hypergrove.com>wrote:
> Sure.
> I would like to apply different protection to logical properties versus
> presentation properties versus wikitext. I would like different semantic
> forms for logical properties versus presentation properties; I don't want
> one long long form that contains numerous tabs for both sets of information.
>
> More broadly though, simply saying that talkspaces are for
> 'discussions-only' doesn't resonate for me because what you seem to be
> saying is that effectively 50% of a wiki is "off-limits" for use as a
> semantic resource. That's disturbing when I've pointed out benefits
> from more exploitive views of those namespaces.
>
> And I provide a solid rationale. There is no doubt that the material found
> on talk-pages is about the subject-resource, and there is no doubt that over
> time text processing engines will be able to detect properties applicable
> to the subject-resource from the talk-page contents. Accordingly, to deny
> that there is no relation between the two pages -- in the manner
> specifically as I've suggested -- seems a bit short-sighted. Talk pages
> contain discussions, yes, but all of which are supposed to be *about* the
> resource. I am saying it's time to bake this reality into smw. And I hope
> that it's not very hard!
>
> Thanks.
>
> -----Original Message-----
> *From:* yaro...@gmail.com [mailto:yaro...@gmail.com]*On Behalf Of *Yaron
> Koren
> *Sent:* Tuesday, April 05, 2011 12:11 PM
> *To:* jmccl...@hypergrove.com
> *Cc:* semediawiki-devel@lists.sourceforge.net
> *Subject:* Re: [SMW-devel] Talkspace Semantics
>
> 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
>
>
--
- Laurent Alquier
http://www.linfa.net
------------------------------------------------------------------------------
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
