On Thu, Nov 25, 2010 at 11:00 AM, Jakob Voss <[log in to unmask]> wrote:
> On 25.11.2010 16:17, Simon Grant wrote:
>> Q: "When did this band play in your town?"
>> A: "They gave a concert at 2nd and 3rd June"
>> Q: "Oh, they started playing at 2nd and finished at 3rd?"
>> A: "No, they gave two shows, one at 2nd, one at 3rd."
>> Q: "But which date did they play?"
>> A: "At 2nd, and 3rd, as I said."
>> Q: "But '2nd and 3rd' is not a date!"
>> And we aren't (I suggest) trying to represent "the" date of complex
>> constructs like this. The reality is just as you say: there is a set of
>> concerts, and each concert had a date (and a time interval within that
>> date). Surely that is enough for any knowledge representation system.
> There is no "the reality is just as you say" if you deal with data. If you
> do not want to allow entities to have multiple dates - fine. If you want to
> model entities with multiple dates - also fine. But none of the two choices
> is "enough" or "reality".
>> Does anyone really want to represent dates of this kind of complex
>> construct? If so, why on earth? If we can get a simpler specification by
>> leaving out a doubtful edge case, I would suggest it was very much worth
>> leaving it out.
> Using the same argument I propose to replace all Date/Time Standards by the
> following easy specification. There are three values:
> Surely that is enough for any knowledge representation system. Why on earth
> would anyone want more complex dates? Relax, have a smoke and enjoy
> present! You can also think about past and the future, but don't be
If I may try to split the difference here, we do need to ground what
we're doing here in practical use cases. And I do think you're
stretching things on this one.
I was trying to imagine a possible example, and having a hard time.
But perhaps an event (like a conference, workshop, hearing) that takes
place over a number of non-consecutive days?