Discussions on Time

Also, the integer type doesn't have enough precision to record some of the periods e.g. Late Jurrasic 161.2 ± 4.0 to 145.5 ± 4.0 million years ago,

We should use the same pattern for uncertainty that we used on Atomic mass.

Thanks for fixing this up. I typed a bunch more topics with the newly revamped type, but many of them still need their dates filled in.

I spent a bunch of time poking around Wikipedia, trying to see if there was an easy way to extract the dates from the infoboxes, but the date range information is tucked away somewhere not easily extractable, alas.

Best way, I think, would be for someone to create a schema in their private user space and then mark it as public and post a link to it here so we can review and comment on it.

Which properties exactly?

Dates of first and final "occurance": http://www.freebase.com/type/schema/time/recurring_event

I fixed the display name, but not the key as that might break code.

Indeed.  Fixed.

We went through this ages ago, and for a while even had a "historic period" type, but in fact we came to the conclusion that these are just really long events.  So type them as "Event", and make the Location property be the relevant places.  Eg. the Federation Period is relevant to Australia.

Oops!  Thanks for catching that!

Cool. I notice that you changed the display name, but not the property key. I can certainly appreciate the app compat reasons for this. Is the intent that it's stuck that way forever?

Yes, pretty much.  If you root around in the Freebase keys, you can find all kinds of examples of mismatches between key and display names.

there should be a way to add an additional key for this property, such that both keys will work...

There is, but it's not working for some reason (in the client, anyway). I've created a bug for it, though: https://bugs.freebase.com/browse/CLI-7337

Oops. Thanks for catching that -- I made it non-unique, now.

Thanks.

Try now. "Calendar" was already a property of "day of year", so I just made it a disambiguator.

The calendar property probably shoud be unique.  Time-admins: do you have any thoughts on this?

I agree it should be unique, and I doubt it will break anything to do so.

I've made it unique, and for lagniappe, I've added the calendar system to our existing days of the year.

Oops, there is Time Interval, but it is in the measurement units domain, not the time domain.

You can just use the type "date/time", which allows for any degree of accuracy from year down to seconds.

oops, my bad, didn't notice the option for varying degrees of accuracy. thanks!

I can't seem to browse by Year. Am I missing something?

I'm not sure what you mean -- what are you trying to browse?

I favor a generalized "Event" with start and end dates. This allows ad hoc creation of various timelines and historic periods. In the case of well-defined historic periods, they could be described as events, tagged with some sort of classification system, and stitched together through an application into a timeline.

I created an Historical period type in my Summary statistics domain to hold this kind of information. Try it out and let me know how it works. Also of relevance is my new Dated location type to track both when and where topics are made or occur. Both are very simple and should therefore handle any situation when a period of time is of importance (e.g., lifespan of philosophers, constuction dates of skyscapers). If you don't restict it to a single value then the Dated location can even be used to track topic occurrences over space and time (e.g., product manufacturing locations).

Upon reflection, maybe my Historical period should be renamed "Time span". Thoughts?

Ed, I prefer "Time span" as a name.  We should probably consider all this in the context of the Event refactoring I have in train, which I should probably post about on the data-modeling mailing list, but basically it seems like almost everything that has a start/end date is, in some way, an event or time period, and making "supporting types" that provide nothing more than start/end dates might be really handy for easily querying things like "tell me everything that happened on my birthday".

I changed the type's name to Time span. The above "Historical period" link will no longer work.

We use no google data. We use some RSS feeds but we seeded our timeline with the wikipedia database. I will check out the data modeling mailing list. I was disappointed to see that an event is valid in the metaweb schema with no start date and reported it as a bug. It looks like data is classified more by a tagging schema than anything else so far. It will be interesting to follow and I think metaweb is an good project.

Weekday is synonymous with workday. Normally, i.e., Monday through Friday. Day of the week is any of the seven.

That's technically correct, but the real reason is that we goofed when creating the "time" domain and created a "day of week" type when there was already a "weekday" type in the "common" domain. "Weekday" was moved here from common as part of a clean-up effort, but the two types are essentially redundant and should be merged somehow.

This looks small enough to merge manually, since it's just 7 items. Day of Week seems to be the more complete model as it includes the relevant calendar as an attribute. I vote we just blow away "Weekday" entirely. Meanwhile, we could make a note that Weekday is deprecated in favour of DoW.

The problem is that both "day of week" and "weekday" are both the expected types of properties on other types, so any merge has to change those properties as well. "Weekday" is used as the expected type of the open and close times on "retail location", which means that the Concierge application probably uses the type, and of course others might, too.

"Time interval" is a compound-value type, and thus cannot be added as an included type (if I'm understanding current rules correctly). I don't think it should really be an included type, anyway, so much as a property. A historical period is often tied to a location, whereas dates apply equally everywhere (differing calendar systems notwithstanding).

Um, hmm, OK. So should I put my own "start date" and "end date" on "Historic period"?

I've just added "start date" and "end date" to "Historic period". Let me know what you think.

That looks pretty good to me.

Could you add a property Events that takes Historical Events like the Great Depression?

Trs80, the reason I can't do that (yet) is because of the bug I reported here which is preventing me from getting the Event type working properly. But yes, it's my intention to do as you describe.

I didn't get a chance to move these yet today. I'll take a look at "historic site" -- it may be that this should end up in the location domain, not the time domain. I enjoy when relationships go cross-domain.

Robert,

Yes, I'd expect "historic site" to be in the Location domain. Makes sense to me.

K.

Sorry for the delay - I've been having some difficulty with our type moving scripts. I will need to enlist some help from our engineering staff tomorrow.

No worries, Robert. I've got plenty else to keep me amused ;)

Got an issue with my "Event" and "Historical event" types (and potentially with any other subtypes of "Event").

"Event" has properties "Includes" and "Included by", so that eg. WW2 includes the Battle of Midway. So far so good

Now, when I'm editing a "Historical event", say "Crusades", I add included events "First crusade", "Second crusade", etc. What I'd like is to be able to type those included events as Historical events, not just Events, but because the included property is typed as Event, it's just showing up as that.

Is there any way I can set up Historical event (and other Event subtypes) to use *themselves* as the included/includes event types?

Not really, Kirrily. A property currently has a singular expected type. When one type includes another (and thus gets the included type’s properties), there is no way to modify the included properties.

The only option is to change the expected type to "historical event", but I don't know what that does to the rest of your schema. It is perfectly legal, though, for a type to have properties that expect that type.

I haven't, but it should be pretty easy to do. I would guess that it has an included type of "location" to allow containment.

This is a list of them.

Or just pull it out of /usr/share/zoneinfo or wherever your system keeps it. The Wikipedia list is pretty vague and incorrect. Timezones have standard names (ISO? Something like that I guess) and the Wikipedia article seems to be ignoring that.

*googlepause*

What you want is the Olsen Time Zone Database. Sources of Olsen timezone data. In Perl, I'd use DateTime::TimeZone to get at this stuff.

At least one other user has been working on events; his types are here:
http://www.freebase.com/view/domain/user/pvonstackelberg/Futures_Studies

Hi Kirrily -- This matches pretty closely a model we created awhile ago but didn't publish. I particularly like your hierarchical nesting and properties for locations and people involved. I'd be happy to promote that along with your other two types.

I did see a strange pattern though. You included "Australia day" as a commemorative event, which is a bit confusing. Events, particularly as you modeled them aren't recurring -- they are one point in time. I could see "Australia Day 2005" being an event, but not the more general topic.

Maybe there should be a "recurring event" type that's similar but more general to the "holiday" type that already exists (and indeed topic Australia Day is indeed typed as Holiday).

I second the request for a temporal interval type (or something like it) -- I created a "frequency" type for periodicals, with instances like daily, weekly, bi-monthly, semi-annually, etc. but it seems like this would make more sense as a general type.

I'd like to see something like this. Here's a microformat specification based on iCalendar that also allows for easy indexing by other applications:

hCalendar spec .

Here's an implementation that shows the format in operation:

hCalendar creator .