Hi Yaron,
>> ... arguing for an overhaul of the system
?what?
>> I think you basically understand how the caching system works
great
>>but I don't see how moving semantic information to the talk page changes
the situation.
Generally by moving relatively non-dynamic annotations off the display page.
By putting them instead onto a separate, very logically related, page.
By editing that page with Semantic Forms, which creates named transclusion
entities.
By controlling what named transclusions may & may not contain - thus when to
be refreshed.
By caching named transclusions separately from the display page itself.
That's how we 'change the situation' -- by eliminating a quite HUGE amount
of apparently *useless* database processing.
Yaron, I'm not suggesting a system that 'knows all queries' - that would be
dumb.
But it wouldn't be dumb to read/update a triples store until only when its
necessary.
Thanks - John
PS Never talked with you about Drupal or embedding CSS. Rather I mentioned
my difficulties controlling what information is included in the generated
page within <includeonly> <onlyinclude> and <noinclude> elements... I was
proposing at the time something like {{{noinclude}}} etc. I could expand
that idea to incorporate this one.... for instance:
{{{includeonly name=xxxxx}}} {{{for template}}} ... {{{end template}}}
{{{includeonly name=xxxxx}}}
Thanks - John
-----Original Message-----
From: yaro...@gmail.com [mailto:yaro...@gmail.com]On Behalf Of Yaron
Koren
Sent: Thursday, April 14, 2011 1:59 PM
To: jmccl...@hypergrove.com
Cc: semediawiki-devel@lists.sourceforge.net
Subject: Re: [SMW-devel] Talkspace Semantics
Hi,
Ah... I recall having a conversation with someone a while ago (maybe
you) who was talking about doing this kind of thing, with the purpose
of having Semantic Forms be a true content-editing system, like
WordPress or Drupal, where the forms let you set both the content of
each page as well as display settings, like fonts, etc. - whether it
was you or someone else, I'm guessing the intent is the same.
Whether or not that kind of usage of SF is useful, I think you'd have
to agree that it's rare - I'm confident that at least 99% of SMW-using
wikis don't include any presentation-related form fields or semantic
properties. Given that, it doesn't seem like a strong basis, by
itself, for arguing for an overhaul of the system.
As for caching - I think you basically understand how the caching
system works, but I don't see how moving semantic information to the
talk page changes the situation. If you want a query to always be up
to date, then you'll have to re-run it every time a user looks at it -
I don't know how you can get around that, regardless of how the data
is stored.
(The exception to that is if you have a system that knows about all
the queries, and can update them itself whenever the relevant data
changes - that's something that's been discussed before as a new
feature, but I don't think that's what you're talking about.)
-Yaron
On Thu, Apr 14, 2011 at 5:52 PM, John McClure <jmccl...@hypergrove.com>
wrote:
> 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
>
>>
>
>
>
> --
> 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
