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.


On Fri, Mar 5, 2010 at 10:44 AM, John McClure <jmcclure@hypergrove.com> wrote:
See below for comments - thanks, John
-----Original Message-----
From: Yaron Koren [mailto:yaron57@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.


On Thu, Mar 4, 2010 at 5:32 PM, John McClure <jmcclure@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

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 traverseobject nodes & then terminating at a text-node, rather than simply having an unnormalized'camel case' text-node propery name (such as the proposed monstrosity) whichislame from the view that, because it is unnormalized, then by definitionit is not reusable in other contexts.
Obviouslynoone wants to require a page for every date. Rather, queriablebuilt-in Date objects can be simulated &or retrieved by SMWeither from SIOsorMV propertiesassociated with the [[:category:Dates]] page OR from pages in the wiki so categorized.
SIOs seem a better candidate because they are queriable, though MV propertiessuggest better performance.If SIO was used, then each 'date' object would belinkedto the :Category:Dates page via a "Category" propertyfor the date object. If MVPs are used, then each 'date' object would be referenced by say an "Instances" propertythat is attached tothe :Category:Dates page either explicitly or implicitly. Personally I'd think the idealwould 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 valueswithin 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 pagevia an End Dateproperty to a :category:Dates object, viaa Weekday property to a:category:Weekdaysobject, then finally to a text property for the name of the day. Ideally,there'd bea built-in set ofdate 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 wthina 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, likerecording [[Ulysses S. Grant]] page's property:President Of= [[USA]], and to set each of the Vice President pages'propertiesto 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 thinkingan #about functioncan 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|}}}
or to set multiple properties on the target object
|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

WikiWorks MediaWiki Consulting http://wikiworks.com