[Emsan-l] EMSAN database structure proposal

[Kevin Austin]

It seems to me that the question(s) here are the "how" and the "what". Please see my posting of Jan 06 for an outline.


Kevin




On 2010, Jan 10, at 2:27 PM, Ken Fields wrote:

> Hi Lonce,
> I think the issue might be for us to work with Leigh and EARS on that stuff (folksonomies and ontologies),
> while the EMSAN database should make a best effort for now.
> 
> Ken
> 
> 
> 
> On 2010-01-10, at 9:05 AM, lonce wyse wrote:
> 
>> 
>> Gentlemen,
>> 
>>     I can't help thinking of the some of the other performance contexts that people have producing music in.
>> A significant proportion of sonic artwork these days does not have a fixed duration. Either it varies, or is "infinite" (running continuously as an installation, for example). 
>>     This also leads to related issues about work that exists in the context of dance, video, the web, or installations with other kinds of objects and processes. I know it seems to open a Pandora's box, but it might be beneficial to identify some of these as categories rather than lump everything in to a free-text "other" field. An audience-interactive sound sculpture is such a different beast from a 64-channel work diffused in a concert hall and again from a Pauline Oliveros type of performers=listeners meditation. It seems like the structure of the database could and should reflect some of the basic paradigms composers are working in regularly now. 
>> 
>> Best,
>>            - lonce
>> 
>> Battier Marc wrote:
>>> 
>>> Le 6 janv. 2010 à 17:14, Kevin Austin a écrit :
>>> 
>>>   
>>>> For the duration of the work, you may wish to consider the format of
>>>> 
>>>>  00 : 00 : 00    (h : m : s)
>>>> 
>>>> or
>>>> 
>>>>  00:00:00.000   (h:m:s.000)
>>>> 
>>>> This is a common format in some software, and avoids the use of the non-standard quotation marks 
>>>> X: 5'19"; Y: 4'38"; Z: 3'53"
>>>> which have two Unicode codes (U+0027 (39) and U+0022 (34)), and (U+2018 (8216), U+2019 (8217) and U+201C (8220), U+201D (8221)).
>>>> 
>>>> This is a kind of complexity that in my experience, you may wish to avoid.
>>>>     
>>> Absolutely. Thanks Kevin. It would then be expressed as: X: 00:05:19, but it would probably be easy to convert it back to 5'19" in some user display format. So it brings the question of data specification as separate from data display, which shouldn't really be a problem.
>>> 
>>> Any further thoughts on that?
>>> 
>>> Marc
>>> 
>>>