From: John M. <jmc...@hy...> - 2011-04-14 18:29:44
|
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: ya...@gm... [mailto:ya...@gm...]On Behalf Of Yaron Koren Sent: Wednesday, April 06, 2011 5:17 AM To: jmc...@hy... Cc: Laurent Alquier; sem...@li... 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 <jmc...@hy...> 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: lal...@gm... [mailto:lal...@gm...]On Behalf Of Laurent Alquier Sent: Tuesday, April 05, 2011 2:19 PM To: jmc...@hy... Cc: Yaron Koren; sem...@li... 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 Sem...@li... https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |