Hi,
Sorry - I still have no idea what you mean by presentation and logical
properties. Could you give an example of each?
-Yaron
On Thu, Apr 14, 2011 at 3:25 PM, John McClure <jmccl...@hypergrove.com> wrote:
> 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
>
--
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
