Sorry for the jargon Yaron. spo=subject-predicate-object triple.
Presentation properties are concerned either with how logical properties are
to be displayed (eg their visibilty format etc) or are those derived by
association (ie #ask: calls). Logical properties are those which uniquely
distinguish one class of resource from another. The logical properties are
always stored of course, and presentation properties are normally template
parameters (not stored) or are embedded in the presentation itself (eg #ask:
calls).
One of my great concerns is performance, and I have a question for
knowledgeable people that is totally pertinent. I've seen notes here about
how much SMW hits the database, and I've looked a bit at (the smw_parser
code) -- is it true that -- if caching is turned OFF -- all annotations and
#set calls are evaluated, each time a page is displayed, to determine if the
triples for the page are to be updated, not just when the page is submitted?
IOW, is it true that, to avoid that processing each time a page is
displayed, that caching must be turned ON? But if an #ask call is on the
page, then because we'd want the most current information displayed, the
page would HAVE to be not-cached. So the fact that wiki pages are required
to contain both logical+presentation properties, means that caching must be
turned OFF, and the triples db must therefore be constantly checked and
rechecked whenever the page is displayed, not just when it is updated.
These questions underscore my point, that if <includeonly>semantic
data</includeonly> was located on the talk page, and if that transclusion
was then cached, then the only database hits necessary when a
subjectspace:page was displayed were jsut those concerned with #ask calls.
That seems as it should be operationally, and I've noted earler about why it
seems as it should be theoretically. The only provisio I'd add is that
transclusions need be nameable, eg {{pgname#transclusion-name}} would derive
from <includeonly name=transclusion-name>semantic data </includeonly>; the
cache then holding these individually named html entities (that's really all
they are!) -- entities which might even have a direct relationship to the
template-calls created by semantic forms.
The arrangement I've proposed -- logical properties on the talkspace:page
and presentation properties on the subjectspace:page -- seems to me might
dramatically improve performance (while being, fwiw, intellectually nicer).
Any insights about caching & SMW are really appreciated... Thanks, John
-----Original Message-----
From: yaro...@gmail.com [mailto:yaro...@gmail.com]On Behalf Of Yaron Koren
Sent: Wednesday, April 06, 2011 5:17 AM
To: jmccl...@hypergrove.com
Cc: Laurent Alquier; semediawiki-devel@lists.sourceforge.net
Subject: Re: [SMW-devel] Talkspace Semantics
Hi,
I'm confused about a few things - John:
- what do you mean by "logical properties" and "presentation properties"?
- what's a "spo statement"?
And Laurent - what would be an example of a "complex, arcane annotation"?
-Yaron
On Tue, Apr 5, 2011 at 10:02 PM, John McClure <jmccl...@hypergrove.com>
wrote:
Hmm you raise some interesting possibilities however it seems that a
generic capability to store spo triples about any wikipage is much more
ambitious than what I'm suggesting. In my proposal, queries do not change
whatsoever; howebver the SH approach would involve compound queries, first
of the subject-page's own triples, and then of the other-namespace-page's
set of triples to identify those whose subject is the subject-page. That
said, your suggestion is an absolute requirement for instance in the legal
arena whose documents have nothing BUT spo statements (albeit couched in
lovely legalese) that is of course, if one is not interested in documents
being the result of a massive number of cascading transclusions!!! Thanks
for your thoughts. John
-----Original Message-----
From: lalqu...@gmail.com [mailto:lalqu...@gmail.com]On Behalf Of
Laurent Alquier
Sent: Tuesday, April 05, 2011 2:19 PM
To: jmccl...@hypergrove.com
Cc: Yaron Koren; semediawiki-devel@lists.sourceforge.net
Subject: Re: [SMW-devel] Talkspace Semantics
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
------------------------------------------------------------------------
------
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
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
