[tei-council] Grouping traitlike, statelike, and eventlike elements - ID: 3060867

[stuart yeates]

On 22/04/12 04:17, Piotr Bański wrote:
> May I ask the Council to have a look at a ticket that was set to pending
> and this is probably why it didn't make it onto Lou's list (and I wasn't
> nagged by SF even once about it):
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=3060867&group_id=106328&atid=644065
>
> I thought the implementation would be as quick as Lou's summary of what
> we decided in Paris, but things do not seem that easy (the schema
> becomes non-deterministic), unless we decide to split the
> not-so-easy-to-implement listState into listOrgState,
> listPersState, and listPlaceState (listPlaceStateLike? OhMyGoodness...).
>
> I summarised the way I see this in my recent comment on the ticket. If
> this reasoning is found correct, the practical question for the Council
> is: do I have green light to implement the three above-mentioned list
> elements?
>
> Or do we take a different route, for example the route proposed
> tentatively by Sebastian (let me stress that he wrote in a hurry from
> the airport and kept to the logic of the decision made in Paris):
>
>> I think I'd
>>
>>   * make a class model.stateLike
>>   * make trait a direct member of that
>>   * make the other stateLike classes members of it too
>>   * refer to stateLike in listState
>>
>> does that work?
>>
>
> which I think has the semantic problem of mixing three kinds of
> stateLike elements (and thus making it possible to talk about the
> climate of a person and the sex of a place).

Splitting these is the sane approach, I think.

cheers
stuart