sure no problem. Logical properties of an address (page): - Secondary Address, Building Number, Street Name, Street Prefix, Street Suffix, Street Type - City, State, Postal Area Code, Postal Stop Code
Presentation properties of an address (page), used to display it - Hide Address, Show Line 1 & 2 only, Format as single line, Format as postal label - Abbreviate when possible, Abbreviate state, Abbreviate street type - Validate city/state, Validate city/zipcode, Validate state/zipcode - Address Height, Address Width, Address Font, ... ie all relevant CSS parameters - Show all links, Show postal links, Show street link Noone cares to store such presentation properties certainly, though they're critical to *presentation* of an address' page. Presentation properties are naturally just template arguments, but each of them would be fields on a form, which is what got me started on the issue of 'long long forms' and how to sidestep that in some elegant manner. To those who say "hardcode everything" or "force users to learn how to code html, css, wikitext, widgets, and everything else technical" I kindly suggest that's not being sensitive to the needs of the general public when confronted by (semantic) wiki technology. -----Original Message----- From: yaro...@gmail.com [mailto:yaro...@gmail.com]On Behalf Of Yaron Koren Sent: Thursday, April 14, 2011 12:25 PM To: jmccl...@hypergrove.com Cc: semediawiki-devel@lists.sourceforge.net Subject: Re: [SMW-devel] Talkspace Semantics 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
