Here’s a brand new multipurpose FZ-database for you: The Circular Motion – A Great Google-y Moogle-y (Found at FZ in Hungary).
Tour/Gig information was arranged from FZ Shows 7.1 & Giglist, set list information from FZ Shows. Venues were extracted, duplicate venues eliminated, venue pictures downloaded & thumbnails generated, crew information gathered from IINK, links to Zappateers threads extracted semi-automatic. In addition: designing & programming a Google Maps interface.
It seems to belong to Zappateers, and according to the Manual it is made by Nadine & Tom.
And according to me – this is fan-tas-tic. I just can’t get used to the enthusiasism of some music lovers here in the internet – so many great homepages, made with lots of energy and love. Great work – thanks!
Yes, Balint, fan-tas-tic is the word. I just finished putting Nadine & Tom’s database through its paces. In a word – exceptional. I fully recommend it.
Incredible work! As a webdeveloper, I’m a little envious I didn’t come up with this myself. 😉 Kudos to the makers!
A primary feature of an OODBMS is that accessing objects in the database is done in a transparent manner such that interaction with persistent objects is no different from interacting with in-memory objects. This is very different from using an RDBMSs in that there is no need to interact via a query sub-language like SQL nor is there a reason to use a Call Level Interface such as ODBC, ADO or JDBC. Database operations typically involve obtaining a database root from the the OODBMS which is usually a data structure like a graph, vector, hash table, or set and traversing it to obtain objects to create, update or delete from the database. When a client requests an object from the database, the object is transferred from the database into the application’s cache where it can be used either as a transient value that is disconnected from its representation in the database (updates to the cached object do not affect the object in the database) or it can be used as a mirror of the version in the database in that updates to the object are reflected in the database and changes to object in the database require that the object is refetched from the OODBMS.
[quote comment=”9120″]A primary feature of an OODBMS is that accessing objects in the database is done in a transparent manner such that interaction with persistent objects is no different from interacting with in-memory objects. This is very different from using an RDBMSs in that there is no need to interact via a query sub-language like SQL nor is there a reason to use a Call Level Interface such as ODBC, ADO or JDBC. Database operations typically involve obtaining a database root from the the OODBMS which is usually a data structure like a graph, vector, hash table, or set and traversing it to obtain objects to create, update or delete from the database. When a client requests an object from the database, the object is transferred from the database into the application’s cache where it can be used either as a transient value that is disconnected from its representation in the database (updates to the cached object do not affect the object in the database) or it can be used as a mirror of the version in the database in that updates to the object are reflected in the database and changes to object in the database require that the object is refetched from the OODBMS.[/quote]
I am currently singing this to the tune of “The Girl In The Magnesium Dress”.
Theydon Bois – comment of the month! 😀
[quote post=”3017″]Theydon Bois – comment of the month! :-D[/quote]
At *least*! HA. I got yer sprechstimme HANGIN’, boy!
Of course, it would be funnier if that piece weren’t merely ‘formatted for the ears of classical radio stations listeners.’
This is an immense amount of information to discover and keep current, and this workload will make the interconnection device very expensive. However, if we modify the addressing scheme we can make the device’s job easier and have it cost less. Suppose we assign addresses by some type of hierarchy. For example, we can use a geographical hierarchy. There is a machine at DARPA with a geographic name trying to connect to another geographically named machine in the UK. I admit these names are a little long, but we can have the people type in the first part just like they do now and have the computers add the rest. To decide which fiber|wavelength pairing to place a packet, the optical|IP interconnection device only needs look at the geographical address from right to left. As soon as it gets to a field that is not the same as its own address, it knows now to send it to that place. In the example, the destination address of Europe is different from America, so the interconnection device knows it needs to send the packet to Europe. This approach requires the interconnection device to know much less information. It only needs to know some or all of the paths that lead to Europe because all of them eventually get to the United Kingdom. Overall, it just needs to know how to get to the other continents, Mexico and Canada, the other states, and the other towns in Virginia. Clearly, that is easier than keeping track of the exact paths to everywhere on the planet.
[quote comment=”9125″]This is an immense amount of information to discover and keep current, and this workload will make the interconnection device very expensive. However, if we modify the addressing scheme we can make the device’s job easier and have it cost less. Suppose we assign addresses by some type of hierarchy. For example, we can use a geographical hierarchy. There is a machine at DARPA with a geographic name trying to connect to another geographically named machine in the UK. I admit these names are a little long, but we can have the people type in the first part just like they do now and have the computers add the rest. To decide which fiber|wavelength pairing to place a packet, the optical|IP interconnection device only needs look at the geographical address from right to left. As soon as it gets to a field that is not the same as its own address, it knows now to send it to that place. In the example, the destination address of Europe is different from America, so the interconnection device knows it needs to send the packet to Europe. This approach requires the interconnection device to know much less information. It only needs to know some or all of the paths that lead to Europe because all of them eventually get to the United Kingdom. Overall, it just needs to know how to get to the other continents, Mexico and Canada, the other states, and the other towns in Virginia. Clearly, that is easier than keeping track of the exact paths to everywhere on the planet.[/quote]
Is part three up yet?
Global Autonomous Language Exploitation (GALE) will solve difficult technical challenges via aggressive, tightly integrated, multidisciplinary research, producing prototype systems able to transcribe and translate foreign language data into English and to deliver pertinent, consolidated information to military users. GALE capability consists of three integrated parts: transcription, translation, and distillation. Transcription, or the conversion of speech to text, is the first step in exploiting foreign language audio information. Translation is the conversion of foreign language text into English text, and is carried out on text transcribed from audio or obtained from foreign language text sources. GALE engines perform both of these processes in a completely automated fashion, without the intervention of human linguists.Distillation is a concept entirely new to GALE, in which relevant information is extracted from foreign language and English input and concisely presented to the user in English. GALE distillation is not a key-word search, and does not involve summarization. Instead, it utilizes language analysis techniques to identify information relevant to a user’s query, with the aim of extracting all available relevant information and nothing redundant.
[quote comment=”9128″]Global Autonomous Language Exploitation (GALE) will solve difficult technical challenges via aggressive, tightly integrated, multidisciplinary research, producing prototype systems able to transcribe and translate foreign language data into English and to deliver pertinent, consolidated information to military users. GALE capability consists of three integrated parts: transcription, translation, and distillation. Transcription, or the conversion of speech to text, is the first step in exploiting foreign language audio information. Translation is the conversion of foreign language text into English text, and is carried out on text transcribed from audio or obtained from foreign language text sources. GALE engines perform both of these processes in a completely automated fashion, without the intervention of human linguists.Distillation is a concept entirely new to GALE, in which relevant information is extracted from foreign language and English input and concisely presented to the user in English. GALE distillation is not a key-word search, and does not involve summarization. Instead, it utilizes language analysis techniques to identify information relevant to a user’s query, with the aim of extracting all available relevant information and nothing redundant.[/quote]
Part three is up!
thx for mentioning us 🙂
we have a new feature – upload picture(s) of a gig. here you can see what it’s about: http://www.zappateers.com/bb/viewtopic.php?p=168008#168008
maybe some of you can help to improve the collection?
regards
tom