Hi John,
I read through this email a few times now, and I still can't really
understand it.
- what's the "camel case monstrosity" you're talking about?
- what's "Category:Dates"? What would go into such a category?
- what's the weakness you see in Semantic Internal Objects?
- would your proposed #about function update the data for a page other than
the one it's on? If so, that seems like a non-starter, but maybe I just
misunderstood it.
I should note, though, that I still don't think is relevant to the
recurring-events issue. It's already possible, in theory, to define a
recurring event as just a start date, an end date, and a set of rules. The
problem is that that would be extremely slow - to find all the pages that
have a certain date value, you'd have to go through all the pages where
dates were defined, apply all the rules, and see if there's a match in any
of them. I don't think it would take a lot of data to make that unworkable.
-Yaron
On Fri, Mar 5, 2010 at 10:44 AM, John McClure <jmccl...@hypergrove.com>wrote:
> *
>
> See below for comments - thanks, John
>
> -----Original Message-----
> From: Yaron Koren [mailto:yaro...@gmail.com]
> Sent: Thursday, March 04, 2010 4:59 PM
> To: John McClure
> Cc: David Raison; semediawiki-devel
> Subject: Re: [SMW-devel] Recurring Events: "Every first saturday of a
> month"
>
> This is interesting, though it seems irrelevant to this discussion, which
> is about storing data, not querying it... unless I'm missing something.
>
> -Yaron
>
> On Thu, Mar 4, 2010 at 5:32 PM, John McClure <jmccl...@hypergrove.com>wrote:
>
>> >Does anyone else have a suggestion? :)
>>
>> Normalization would show the day of a week is an attribute of a date. So:
>> * An #ask should be able to say ?Date.Weekday
>> * IOW, a "Date" is a first class object as much as, say, a "Place" is
>> * IOW, I'd like to see SMW standardize "category:Dates" and its properties
>> * And I'd like to see the ability to set those properties from a
>> 'container'
>> object's template but see below my idea for an #about function
>> * IMHO, {{#set: page-or-sio-name|propname=value}} would resolve alot of
>> n-ary
>> issues but see below discussion for the #about function
>> <snip>
>>
> **
> ------------------------------
> *
> I worked backwards to address the storage process & protocol, starting
> from the query that I'd rather see. The query is one that uses the 'dot'
> operator to traverse object nodes & then terminating at a text-node, rather
> than simply having an unnormalized 'camel case' text-node propery name (such
> as the proposed monstrosity) which is lame from the view that, because it is
> unnormalized, then by definition it is not reusable in other contexts.
> **
> Obviously noone wants to require a page for every date. Rather,
> queriable built-in Date objects can be simulated &or retrieved by SMW either
> from SIOs or MV properties associated with the [[:category:Dates]] page OR
> from pages in the wiki so categorized.
>
> SIOs seem a better candidate because they are queriable, though MV
> properties suggest better performance. If SIO was used, then each 'date'
> object would be linked to the :Category:Dates page via a "Category"
> property for the date object. If MVPs are used, then each 'date' object
> would be referenced by say an "Instances" property that is attached to the
> :Category:Dates page either explicitly or implicitly. Personally I'd think
> the ideal would be to have MVPs that are queriable in the normal #ask
> methods, enhanced to reference a metaproperty for the 'Instances' property
> that lists the property names by which to retrieve values within each MVP
> arraymap.
>
>
> So I'm urging a new data model from the get-go, to arrive at simple
> reusuable syntax like "End Date.Weekday.Text" -- involving navigation from
> any page via an End Date property to a :category:Dates object, via a Weekday
> property to a :category:Weekdays object, then finally to a text property for
> the name of the day. Ideally, there'd be a built-in set of date objects
> that can be referenced by others, whose properties can be extended by a wiki
> (ie defining additional rdfs:domains for the class), and that can be created
> as pages wthin a wiki.
> ------------------------------
> My problem with SIOs or MVPs as an n-ary solution is this:
>
> Assume a template for a [[:category:Country]] page named "USA" has:
> {{#set_internal:Is president of
> |Has name=Ulysses S. Grant
> |Has vice president#list=Schuyler Colfax, Henry Wilson
> }}
> What I want is to do simple housekeeping, like recording [[Ulysses S.
> Grant]] page's property:President Of = [[USA]], and to set each of the Vice
> President pages' properties to reflect their relationship to [[Ulysses S.
> Grant]]. Defining complementary properties gets very messy very fast, so it
> HAS to be able to be done in the template that creates the SIO. This can
> make queries of [[Ulysses S. Grant]] much easier.
>
> I'm thinking an #about function can implicitly update arbitrary pages when
> in the context of another page, such as setting [[Colfax]] page properties
> when processing a template embedded in [[USA]]. Provenance fields
> identifying the data source etc could be collected by the #about function.
> So to set a complementary property ("Presidency") to the ("Is President Of")
> property, there'd be something like
>
> {{#set_internal: Is president of :: {{FULLPAGENAME}}#{{prez_name}}}
> |Has name={{{prez_name}}}
> |Has vice president#list={{{prez_vps|}}}
> }}
> {{#about::{{{prez_name}}}
> |Presidency={{FULLPAGENAME}}#{{prez_name}}}
> }}
> or to set multiple properties on the target object
> {{#about::{{{prez_name}}}
> |Is president of={{FULLPAGENAME}}
> |Has vice president#list={{{prez_vps|}}}
> }}
> **
> If a Weekday name is being set for a certain date, then:
> {{#about: Category:Dates#2010-03-04
> |Weekday=Category:Weekdays#Thursday
> }}
>
>
>
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
