MUSICJSON: A REPRESENTATION FOR THECOMPUTER MUSIC CLOUD

Jesus L. Alvaro Beatriz Barros

Computer Music Labfauno.org, Madrid, Spain

Dpto. Lenguajes y Ciencias de la ComputaciónUMA, Málaga, Spain

JesusLAlvaro@gmail.com bbarros@lcc.uma.es

ABSTRACTNew cloud computing ways open a new paradigm formusic composition. Our music composing system is nowdistributed on the Web shaping what we call as ComputerMusic Cloud (CMC). This approach benefits from thetechnological advantages involved in distributedcomputing and the possibility of implementing specializedand independent music services which may in turn bepart of multiple CMCs. The music representation used ina CMC plays a key role in successful integration. Thispaper analyses the requirements for efficient musicrepresentation for CMC composition: high musicrepresentativity, database storage, and textual form.Finally, it focuses on its textual shape, presentingMusicJSON, a format for music information interchangeamong the different services composing a CMC.MusicJSON and database-shaped representation, bothbased on an experienced sound and complete musicrepresentation, offer an innovative proposal for musiccloud representation.

1 . INTRODUCTIONCloud Computing, a new term defined in varied ways [7],involves a new paradigm in which computer infrastructureand software are provided as a service [5]. This servicesthemselves are referred to as Software as a Service (SaaS).Google Apps is a clear example of SaaS [8]. Computationinfrastructure is also offered as a service (IaaS), thusenabling the user to run the customer software.

This new paradigm offers new possibilities for thedesign of composition systems. Fig. 1 shows theComputer Music Cloud (CMC) approach where thesystem is distributed across specialized online services[2]. The user interface is now a web application runningin a standard browser (1). A storage service is used asan edition memory (2). An intelligent-dedicated serviceis allocated for music calculation and development (3).Output formats such as MIDI, graphic score and sound fileare rendered by independent services exclusively devotedto this task (4). The web application includes user sessionsto allow multiple users to use the system. Both publicand user libraries (5) are also provided for music objects.Intermediary music elements can be stored in the libraryand also serialized into a MusicJSON format file, asdescribed below.

Fig. 1. Basic Structure of a Composition MusicCloud

This CMC approach has several advantages. Some ofthem come from Cloud Computing, such as scalability,optimization and reuse of available resources. Otherscome from web applications, such as decentralizedinformation, being able to work from any computer witha standard Internet connection and browser, and theinherited code. Also, the division of the music systeminto services allows for the design and implementation ofindependent services with the most appropriate tools, It isapart from the availability of a service for different CMCsystems. Since services can be shared, the design of newmusic systems is facilitated by the joint work of differentservices controlled by a web application.

The key factor in successful integration is the use ofa well-defined music representation for music datainterchange. This is also the objective of this paper:presenting a proposal for the interchange of musicinformation among the services which shape a musiccomposition cloud. In the next section, the types ofservices included in this cloud are analysed as a baseto define the requirements to be fulfilled by the selectedmusic representation, tackled in Section 3. Section 4describes the MusicJSON format as a textual form ofthe used representation, while Section 5 describes someuse examples. The paper ends with some conclusions andsome points referred to related work.

2 . MUSIC SERVICES IN THE CMCIn a simple form, Music Web Services are serversreceiving a request and performing a task. At the endof a task the resulting objects are returned to the stream

Copyright: © 2010 Jesus L. Alvaro. This is an open-access articledistributed under the terms of the Creative Commons AttributionLicense, which permits unrestricted use, distribution, and reproductionin any medium, provided the original author and source are credited.

or stored in an interchange database. The access to thisdatabase is a valuable feature for services since it is ashared workspace where the componets of musiccomposition are represented. The Music Services of thecloud can be classified according to their function. Theseservices are described in the following subsections.

2.1 InputThis group includes the services aimed particularly atincorporating new music elements and translating themfrom other input formats.

2.2 AgentsThey are those services which are capable of inspectingand modifying music composition, as well as introducingnew elements. They include human user interfaces, butthey may also consider other intelligent elements takingpart in music composition[4]: introducing decisions,suggestions or modifications. In our prototype, we havedeveloped a web application [2] acting as a user interfacethrough the edition of music objects.

2.3 StorageThere are two main types of storage services: libraries andcomposition environments. Libraries store music objectswhich shall be used in different compositions. There aregeneral libraries and user libraries. Main lib stores sharedmusic elements as global definitions. This contentcomprises music elements shared by all users as a sharedmusic language. User-related music objects are stored inthe User lib and include composer-defined music objectswhich can be reused in several parts or compositions.

Composition environments are the storage serviceswhere the piece is progressively composed. This databasecontains the composition environment (i.e., everythingrelated to the piece currently under composition), and doesnot only act as a space for information interchange, butalso as a real and shared music environment with whichseveral services can interact simultaneously andcoordinatedly.

2.4 DevelopmentThe services in this group perform development processes.As explained in [1], development is the process by whichhigher-abstraction symbolic elements are turned intolower-abstraction ones. High-abstraction symbols areimplemented as meta-events and represent music objectssuch as motives, segments, and other composingabstractions [1]. Algorithmic composition developers andother intelligent services, such as constraint solvers orgenetic algorithms, are examples of this type of musicdevelopment service .

2.5 OutputThese services produce output formats as a response torequests from other services. They render formats fromthe element currently under edition for immediatecomposer feedback as well as the whole score or audio.The MIDI file for audio playing and standard notation in

a graphic format are two clear examples of this. Otheroutput formats are also possible by integrating a suitabletranslation service.

3 . MUSIC REPRESENTATION FOR THECMC

To achieve an effective integration of all elements in thecloud for music composition, all services must share thesame music representation. This representation must meetthree main requirements: satisfactorily represent the basicelements of music composition in a solid hierarchy ofclasses; present a representation form for storing musicobjects in a database; and count on a textual form whichfacilitates the interchange of music objects among thedifferent services. Besides, the cloud's distributed naturemust also be taken into account by incorporating thepossibility of distribution in the data. All these elementsare described in the following subsections.

Fig. 2. Abstract, Database and Textual Formsof Music Representation

3.1 EVMusic RepresentationThe proposal is based on EVMusic representation [1]. Itis a robust model with high multi-level representativity,multiple topologies and meticulous, detailedrepresentation of music pitch, as well as full compatibilitywith traditional music notation. Likewise, its multi-levelnature and expandability allow for representing musicelements at varied abstraction levels.

EVMusic representation counts on a completehierarchical organization of classes designed in theplatform-independent UML [13], which allows for its usein multiple programming languages. Figure 3 shows abrief extract from the UML representation, showing onlysome of the classes present in the music fragment inFigure 6, which shall work as a reference for subsequentexamples. The present paper is not aimed at contributinga detailed analysis of EVMusic classes. Nevertheless, weshall contribute a brief description of some of the mostrelevant aspects shown in this figure, particularly therelations.

In a UML Class Diagram [12], the inheritance relationamong classes is represented with a hollow pointed arrow.Thus, it can be observed in this figure that a scoreelementis an event, which in turn is a treeobj just like singlepitch.Inheritance relations can also be multiple, as it occurs with

the note class. Thus, it can be deduced that a note is eithera score element with a unique pitch ,or a pitch temporarilyplaced on the score.

Containment relations are indicated by means ofrhombus-shaped arrows and the name of the relation.Thus, it can be observed in the figure that an object ofthe aggregate class includes an attribute known as pitches,which is a container of singlepitch-like elements.Therefore, a chord (an nchord-like object) which inheritsthe aggregate properties is a scoreelement which containsseveral singlepitches. Grace notes are also representedwith a content relation: they are a sequence ofsinglepitches which ornament a scoreelement and arestored in its slot known as graces. Finally, the structure ofsimilar objects is also indicated by the content relation. InEVMusic, each event is by default a group of subevents,as clearly reflected in the fractal-like structure of musictime. Thus, these subevents are stored in the slot events ofthe main event. The tree structure is represented by meansof the treeobj class and its parent relation. It is extendedto all representation elements and shall be commented onin the following section.

Fig. 3. UML Diagram with some classes ofEvMusic Representation

3.2 Database Stored RepresentationDatabase storage allows several services to share the samedata and collaborate in the composition process. Theinformation stored in a database is organized in tablesof records. The database representation must achieve twoobjectives: store music instances and store the relationsamong these forms.

Figure 4 shows a simplified scheme with somedatabase fields. To represent the objects of a particularclass, the table of the database incorporates the fieldobjclass, which contains the name of the object class.The attributes of each class are usually represented by

fields with the name of the attribute. In this figure, theseattributes are indicated in the rows of predefined attributes(AttributeA, AttributeB,...) Importantly, appropriaterepresentations must enable the incorporation of newelements, even those which have not been defined yet.Some pairs of generic fields have been provided withthis purpose. These pairs of generic fields store both thename of the attribute and its value. They are indicated inthe central rows of this figure as Expandable Attributes.For instance, if we want to incorporate a new attributeknown as "zattrib", the register will contain "zattrib" in thefield attrib1name, and its value in the field attrib1value.Thus, implementing a new storage system is not necessarywhen a new class, with its new attributes, is defined.

Fig. 4. Record Structure of Data Base

The relations among the music objects are alsorepresented in the database. Among all of them, thecontainment or belonging relation is likely to be the mostimportant one. As we have already mentioned, the musicobjects of the abstract EVMusic representation are usuallytree-shaped related. To be stored in a database, these treestructures must be previously converted into records. Forthis purpose, the three main classes of EV representationare subclassed from a tree node class treeobj, shown inFig. 3. Thus, every object is identified by a uniquereference and a parent attribute. This allows to representa large tree structure of nested events as a set of records forindividual retrieval or update. By default, the slot parentalways refers to the containment relation. However, otherrelation can be used for this main tree. The fieldparentrelationship (abbreviated as rel) was incorporatedwith this aim. For instance, the last row in Table 1, showshow the grace note indicates the main note nt03 as parent,but the parent relationship in this case is not a temporarystructure, but a grace-note structure, so its value in thefield rel is "grace".

The representation of relations has been completed byincorporating new relatives. As it can be observed inFigure 4, the main relation parent was added pairs offields aimed at indicating new relatives. Thus, forinstance, a new relation r1 can be incorporated byindicating the reference of the referred object in the fieldrelative1 and the relation between them in the fieldr1relationship. The incorporation of new relations in the

database contributes an important degree ofrepresentativity since it opens new creative andrepresentative possibilities, such as, for instance, theopportunity of representing constraints among musicobjects or the definition of some objects according toothers. Multiple relations also allow for the coexistenceof several organizations of objects, letting , for instance,the same note belong to both a temporary structure(represented by the relation parent) and a harmonicstructure (represented by an extended relation)simultaneously.

Table 1. Database Content for a simpleexample

Table 1 shows the database content for the music examplenotated in Figure 6. The objclass field indicates the classof every instance. Note the relation with the musicexample and the following listing code in Section 4.1

The music objects described in the database of a musicstorage service can belong either to the environment of themusic piece currently under composition, or to a generalor user library. Library objects are referred to by otherobjects by putting the prefixes x.lib and the reference ofthe library before the reference of the object, as we shallsee in the following examples.

3.3 MusicJSON Textual RepresentationThe third specification which must be met by the CMCrepresentation is counting on a textual form which allowsmusic information to be interchanged among servicesthrough web streams.

When it comes to design an appropriate textual formatfor data, basing on formats already widely-used in theInternet seems a rather convenient strategy. Webapplications usually use XML and JSON (Java ScriptObject Notation) [11] for data interchange. Both formatsmeet the requirements. XML has been successfully usedfor score representation [15]. However, we opted forJSON, mainly due to the large JSON-compatible toollibrary available at the time of writing this paper, andthe fact that JSON is the interchange format for some ofthe main Internet web services such as Google or Yahoo.In addition, JSON provides great features such as humanreadability and dynamic unclosed object support, a veryvaluable feature inherited from the prototype-based natureof JavaScript [10]. To facilitate communication, JSONalso offers JSONP [9] and its corresponding libraries for

web applications, which extends interaction flexibilityamong web services.

As mentioned in [11], "JSON is a lightweight data-interchange format. It is easy for humans to read andwrite. It is easy for machines to parse and generate.[...]JSON is built on two structures:

• A collection of name/value pairs. In variouslanguages, this is realized as an object, record,structure, dictionary, hash table, keyed list, orassociative array

• An ordered list of values. In most languages,this is realized as an array, vector, list, orsequence."

These universal data structures in JSON can be used todescribe EvMusic objects and communicate among webmusic services. MusicJSON is the name given to this use.Once the database-shaped representation has beendetailed, MusicJSON is easily understandable since theyare directly and closely related. MusicJSON can beunderstood as a serialization of database content.MusicJSON objects are therefore collections of key/valuepairs which have been assigned the afore-describedattribute objclass, so each object always declares its class.

Fig. 5. A note instance in UML, database andMusicJSON representation

To give a simple example, Figure 5 shows the same objectas an instance in a ULM diagram, as an entry in thedatabase, and as a MusicJSON text. Please observe thatthe textual representation includes the attribute objclasswith the value "note".

The code in Section 4.1 shows a more illustrativeexample applied to a brief music fragment. Compared toits standard notation in Figure 6, and Table 1, MusicJSONcode is easily understandable. In order to improve thereadability, some data semantics are allowed inMusicJSON, like the use of pitch names instead ofnumbers, as shown in the code.

In MusicJSON not all the attributes of the object arenecessary, but only the relevant ones (i.e., those necessaryfor object definition and abstract-instance construction).If the values corresponding to a necessary property arenot indicated, the default values of its corresponding class,or even specific default values defined for a particulargroup of objects shall be taken. The key defaultcontent isprovided with this purpose.

Regarding structures, represented in the database ascontent relations among entries, MusicJSON is not a mereserialization of each database register. It can representarrays or lists, so structures are presented directly in adeployed form. This tree structure can be observed in thelisting code in Section 4.1, which spreads completely thetree score -> section -> staff -> part -> note.

Table 2. Extended references in MusicJSON

Other valuable feature of MusicJSON is related to itsdistributed nature: extended references. Like a hyper-document, MusicJSON allows for the use of externalobjects either from a library or directly. A new kind of xrefobject was defined with this purpose. The following tableshows some types of extended references such as externalobjects by means of URL, elements of an imported library,elements defined in a variable, or contextual elements.

Referred objects can be used in two ways: eitherdefining an xref-type object (as shown by the thirdcolumn), or using directly the extended reference with thenotation of prefixes separated by dots (as shown in thelast column). The former section has already shown howlibrary objects are referred to with the prefix x-lib. Theextended reference for an external object is denoted bythe prefix x.url followed by the URL of the object. Theindividual and direct references to a previously-definedobject are indicated by the prefix x.def followed by thereference previously defined within the same context.

The incorporation of xref objects and extendedreferences is an important value added to textualrepresentation since it allows for combining variedelements which can be distributed in the Web. Arguably,this makes it a valuable feature for a knowlegderepresentation for the Cloud. In addition the use ofextended references, is open to the definition of newreferences by using new prefixes. For instance, the lastrow in Table 2 shows a reference to the context of musicaltime, denoted by the prefix x.ctx.mtime. The time contextof a music object is very important, as in harmony. Forinstance, an extended reference of this type enables thedefinition of an object which depends on the currentharmonic context.

4 . MUSICJSON IN EXAMPLESThis section shows some illustrative examples of the useof MusicJSON.

4.1 Music Fragment in Traditional NotationAs previously stated, MusicJSON is compatible with thetraditional notation. For the sake of illustration, weinclude a simple example of traditional notation of a briefmusic fragment and its corresponding representation inthe MusicJSON format. All music objects in the exampleare represented in the UML diagram of Figure 3. NoteMusicJSON's high readability and clear relation totraditional notation. Also note the generic tree structureof a score: score -> section -> staff -> part -> note, atthe beginning of the code, and the relation to the databasecontent in Table 1 representing the same music example.

Fig. 6. Score notation of the example

{"objclass": "score","pos": 0,"events": [{

"objclass": "section","pos": 1,"events": [{

"objclass": "staff","name": "Violin","pspellorder": 1,

"events": [{"objclass": "part","track": 1,"pos": 1,"events": [{

"objclass": "note","pos": 0,"dur": "0.5","pitch": 69,"art": "st""dyn": "mf",

},{

"objclass": "note","pos": 0.5,"dur": "0.5","pitch": 69,"art": "st"

},{

"objclass": "note","pos": 1,"dur": "0.75","pitch": "d5","legato": "start","graces": [{

"objclass": "spitch","pitch": 76

}]},{

"objclass": "note","pos": 1.75,"dur": "0.25","pitch": 73,"legato": "end"

},{

"objclass": "note","pos": 2,"dur": "0.5","pitch": 74,"art": "st"

},{

"objclass": "note","pos": 2.5,"dur": "0.5","pitch": 76,"art": "st"

},{

"objclass": "nchord","pos": 3,"dur": "1","pitches": [{

"objclass": "spitch","pitch": "f#5"

},{

"objclass": "spitch","pitch": 69

}]

}]

}]}]

}]}

4.2 Storage Service AccessThe interchange of musical information between theservices of the CMC can be done directly, but it is alsopossible to exchange it in a shared form through thedatabase. Any exchange of information with the StorageService is done in MuiscJSON format; not just musicalobjects, but also the communication protocol. The storageservice responds to standard GET requests with a URLthat ends with the function to perform, usually a CRUDfunction (Create, Retrieve, Update, Delete). The requestis accompanied by two parameters: a data parameter withinformation in MusicJSON format and a second parameternamed callback, as the JSONP function to be returned.To give an example, Table 3 shows a complete updaterequest to change the duration of note with ref "note_84"to a new value of 12.

url http://evmusic.fauno.org/storage03/update

callback stcCallback1002

data {"duration":12,"ref":"note_84"}

Table 3. MusicJSON request parameters

After updating the corresponding data in the storageservice, the returned response has the following form:

Callback({"message": "Message Content","data":[responsed data], "success": true})

This means that the returned data are sent back along witha status message confirming the transaction, everythingencapsulated in a function with the name of the callback,as required by the JSONP data transaction, so the servicecan accept AJAX requests from other domains. In ourexample, here is is the response received to the updaterequest above:

stcCallback1002({"message": "Updatedrecord", "data": {"track": "1", "objclass":"note", "pitch": "39", "start": 6,"duration": 12, "ref": "note_84", "id":84}, "success": true}

4.3 Library UseLibrary services can make use of predefined musicalobjects. To use a library service, this must be declaredin lib section of the document in a key-value pair. Thereference name for that library is assigned as the key,while the URL that returns the library itself, usuallyencapsulated as JSONP, is assigned as the value.

"lib": {"main": "http://evmusic.fauno.org/lib/

main/instruments",... ,

}

The content of the library returned from the given addressis:

LibraryCallBack({"message":"Sent data: 45 entries","data":{"flute":{

"objclass":"pinstrument","families":[

"wind", "air","wood", "woodwind"],

"clef":"treble","transpose":0,"stafforder":1.2,"constraints":{

"minpitch":"c4","maxpitch":"c7","usualpitch":"g5","polyphony":1,"maxtime":12,"maxspeed":90,"maxlegatointerval":17},

"techniques":["frullato", "whistle","air", "keysound"]

},"oboe":{

"objclass":"pinstrument",...}

...},"success":"true"})

In this case, the complete library is returned, but it isalso possible to ask for only one object from the library,by completing the URL with the key that correspondsto that object. Thus, instead of downloading the wholelibrary, we save memory by downloading only the datawe need. For instance, in order to access only the fluteinstrument, we would use the following URL:"http://evmusic.fauno.org/lib/main/instruments/flute".

In order to use an object from the library, the x.libprefix followed by the library key must be indicated asreference, as shown in Table 2. The MusicJSON codeof the referred object will replace the library call duringparsing:

{"objclass": "scoinstrument","name": "Flauta","value": "x.lib.main.flute"}

4.4 MusicJSON FileEvery EvMusic object, from single notes to complexstructures, can be serialized into a MusicJSON text andsubsequently transmitted through the Web. In addition,MusicJSON can be used as a music format for localstorage of compositions. Next listing code shows a draftexample of the proposed description of an EvMusic file.

{"objclass":"evmusicfile","ver":"1002","content":

{"lib":{

"instruments":"http://evmusic.fauno.org/lib/main/instruments",

"pcstypes":

"http://evmusic.fauno.org/lib/main/pcstypes",

"mypcs": "http://evmusic.fauno.org/lib/jesus/pcstypes",

"mymotives":"http://evmusic.fauno.org/lib/jesus/motives"

},"def":{

"ma": {"objclass":"motive","symbol":[ 0,7, 5,4,2,0 ],"slength": "+-+- +-++ +---"},

"flamenco": {"objclass":"pcstype","pcs":[ 0,5,7,13 ],},

},"orc":{

"flauta": {"objclass":"instrument",

"value":"x.lib.instruments.flute","role":"r1"}

"cello": {"objclass":"instrument",

"value":"x.lib.instruments.cello","role":"r2"}

},"score":{

"objclass": "score","pos": 0,"events": [{

"objclass": "section","pos": 1,"events": [{

"objclass": "staff","name": "flauta","pspellorder": 1,"events": [{

"objclass": "part","track": 1,"pos": 1,"events": [{

"objclass": "note","pos": 0,"dur": "0.5","pitch": 62,"art": "st"

},...

... ]},{"objclass":"section","pos": 60,

...},],}}}

}}

The code shows four sections in the content. The secondsection named lib is a dictionary of libraries to be loaded.Both main and user libraries can be addressed. Thefollowing section includes local definitions of objects. Asan example, a motive and a chord type are defined. Nextsection establishes instrumentation assignments by meansof the arrangement object role. Last section is the scoreitself, where all events are placed in a tree structure usingparts. Using MusicJSON as the intermediarycommunication format enables us to connect severalmusic services forming a cloud composition system.

5 . CONCLUSIONThis paper puts forward a model of musical representationfor the Computer Music Cloud, a new paradigm in whichmusical computing systems are distributed in several

musical services over a computing cloud. This newenvironment allows to build new systems by puttingvarious services to work together. We present a newarchitecture which allows to design specializedautonomous musical services that can be implementedseparately in different platforms, and may even servemultiple systems simultaneously.

Effective integration of such musical services in theCMC depends on the definition of a music representationthat they all share and that will enable efficient exchangeof musical information. Musical representation shouldfulfill three main requirements:1) to have a high andflexible representativity for music composition, 2) toprovide a form allowing music objects to be stored asentries of a database; and 3) to count on a text format thatfacilitates information exchange, as well as the integrationof different data sources.

Our new proposal is based on the robust musicalrepresentation for EvMusic composition described inUML which has proved effective in actual compositionexperiments [1,3]. Above this abstract model of classes,the database form representation and the textualrepresentation MusicJSON have been incorporated.

MusicJSON can represent the complete EvMusic classsystem together with its different topologies and itscomprehensive treatment of musical pitch. In addition tobeing compatible with conventional musical notation, itcan represent higher abstraction structures at multiplelevels. It is not only a simple format for exchange ofmusical objects in text form, but it also integrates musicalinformation from different services. It can also handlereferences to external objects and libraries. Severalexamples of use have been shown: representing a musicfragment, protocol for sharing musical elements betweenservices, use of libraries and the file format. MusicJSONis based on JSON, an increasingly used format on theInternet. Therefore it inherits its expandability andprototyping features, and benefits from its extensivelibrary of available tools and services.

MusicJSON, EvMusic representation and the databasemusical format have been tested in real CMC prototypesthat incorporate different types of music services [2].Significantly, it is one of the first proposals for musicrepresentation in the new paradigm of MusicalComposition in the Cloud. This CMC approach also opensmultiple possibilities for derivative work. Once you definean efficient shared music representation for the cloud, anymusic service can be easily incorporated into the newparadigm: services that translate input and outputrepresentations, some applications for collaborativecomposition among multiple users, musical teachingassistants, and even the integration of true intelligentcomposition agents. It provides a promising environmentfor the research in Musical Artificial Intelligence (MAI),where specialised agents can cooperate in a musiccomposition environment sharing the same musicrepresentation [4]. Likewise, the paradigm shift thatinvolves the CMC, offers new interesting possibilities for

web applications acting as user interfaces in the ComputerMusic Cloud, taking advantage of new technologicaldevelopments such as the upcoming HTML5 [14]

REFERENCES1. Alvaro, J.L., Miranda, E.R., Barros, B. "Music

Knowledge Analysis: Towards an EfficientRepresentation for Composition", CurrentTopics in Artificial Intelligence; LNCS 4177,Springer-Verlag, pp. 331-341(2006)

2. Alvaro, J.L. and Barros, B. "Composing Musicin the Cloud", Proceedings of the InternationalSymposium on Computer Music Modeling andRetrieval, Málaga 2010

3. Alvaro, J.L. : "Painting Music with Motives,Twelve Years of Symbolic Pitch Composition".Under Review

4. Alvaro, J.L. : "Intelligent Music Clouds". To beAppeared

5. Armbrust, M., Fox, A., Griffith, R., Joseph, A.D., Katz, R. H., Konwinski, A., Lee, G.,Patterson, D. A., Rabkin, A., Stoica, I., andZaharia, M. "Above the Clouds: A BerkeleyView of Cloud Computing" {White Paper}http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf.

6. ECMAScript Language Specification,http://www.ecma-international.org/publications/standards/Ecma-262.htm

7. Geelan, J: "Twenty Experts Define CloudComputing", Cloud Computing Journal, SYS-CON Media Inc. ( 2008)http://cloudcomputing.sys-con.com/node/612375/print

8. Google Apps. http://www.google.com/apps/9. Ippolito, B. "Remote JSON - JSONP- JSON

with Padding" (2005)http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/

10. JavaScript. http://en.wikipedia.org/wiki/JavaScript.

11. Introducing JSON: http://www.json.org/12. Martin, R.C. :"UML Class Diagrams" Object

Mentor articles (1997)http://www.objectmentor.com/resources/articles/umlClassDiagrams.pdf

13. OMG,. Unified Modeling Language:Superstructure. Version 2.1.1, Retrieved from:<http://www.omg.org/uml>, (2007).

14. W3C "HTML5 A vocabulary and associatedAPIs for HTML and XHTML" W3C Editor'sDraft http://dev.w3.org/html5/spec/

15. Walter B. Hewlett and Eleanor Selfridge-Field(eds) "The Virtual Score". MIT Press (2001)