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
