Re: [abcusers] RE: ABC transcrivers ID
Hello, Richard Robinson wrote: (...) I dunno. Personally, since I need such a numbering scheme, I'm using a %%ID: line, on the grounds that it won't conflict with any accepted usages; and when I get that sorted out and it reaches my web-collection I'll use another such '%%' line for the 'base' collection, or maybe (probably) to form a URL. Such a scheme will never be more than one person's particular addition unless the writers of the software in use choose to incorporate it. Even then there's always the John Chambers Case - people who read ABC directly and can't even be bothered to include an X: line :- but we can't do anything about that :) I think its quite clear that it is impossible to enforce whatever numbering scheme to all abc format users, so the only question is if we can find a solution that is based on an agreement of a large number of abc collection owners (and programmers) an so reasonable and open that others join it because they find the agreement sensible. It could be something like the identification system in librarys, probably made up the same way (are there librarians out there ?). And the main problem will still not be solved, that nobody can stop people from stripping off all this usefull information when copying the source. Besides this there is a big problem with altered files in general: If I change the apperance of the abc text - like I do it regulary - whose file is it then, if I correct or alter the abc text - the music - what happens then ? Again we could - and should - make up a code of conduct for this cases but there is no way of enforcing this, just the personal decision to follow the rules for the sake of a better world ;-) . An unique ID has to be long: if there are collections which include large sources (1001 tunes... or many tunes of the same kind, one needs at least four digits to to idenify them within the file or collection, and if there are more sources or kinds of tunes, at least three digits for identifying them (better more). If we use letters and numbers for identfying the place, person or collection three digits for this purpose will not be enough if we do not want people to use names like 7QX. So, at shortest a ID has to allow at least eleven digits and, if we want to make these ID's to give further information (person, collection, area ...), eleven will surely not be enough. I opt against Zip codes or geographical names in an ID as they lose their meaning in the same way that URL's do when the person moves. To avoid double use there has to be a record of ID's which are in use or had been used in the past (also this record could contain information about the author like suporting the actuall URL; this record must be at a save place in the net, available for a long period of time). So, I find this idea interesting, but I think this must be discussed and planned in long terms. regards, Simon Wascher - Vienna, Austria Example thats what I got: X:1 T:Valse à Delsay R:valse S:Culture Populaire et Loisirs, Poitou M:3/4 L:1/8 K:G D2 |GDB,DGD|BDB,DGD|B2 ADFA|G2 B2 D2 | GDB,DGD|BDB,DGD|B2 ADFA|1 G4 :|2 G3 |: DGB|d2 dedc|B2 GDGD|c2 ADAD|B2 GDGB| d2 dedc|B2 GDGD|c2 ADAD|1 G3:|2 G4 || thats what I made up for me, and passed on for playing purposes: X:2 T:Valse à Delsay (adaptiert fuer sack-pfeife) R:valse S:Culture Populaire et Loisirs, PoitouZ Z:original abc transcription by Stephan Steiner N:adaptiert by Simon Wascher M:3/4 L:1/8 K:G D2 |\ BGDGBG | dGDGBG | d2 cFAc | B2 d2 D2 |\ BGDGBG | dGDGBG | d2 cFAc |1 B4 :|\ [2 B3 || |: DGB |\ d2 dedc | B2 GDGD | c2 ADAD | B2 GDGB | d2 dedc | B2 GDGD | c2 ADAD |1 G3:|\ [2 G4 || To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE: ABC transcrivers ID
Simon Wascher [EMAIL PROTECTED] writes: I think its quite clear that it is impossible to enforce whatever numbering scheme to all abc format users, so the only question is if we can find a solution that is based on an agreement of a large number of abc collection owners (and programmers) an so reasonable and open that others join it because they find the agreement sensible. Yes. It could be something like the identification system in librarys, probably made up the same way (are there librarians out there ?). I think the `tune/transcription ID' should be similar in spirit philosophically to the `message ID' found on e-mail messages and Usenet postings. That is, it shouldn't a priori try to `classify' the tune according to some set of criteria (which we will never be able to get a consensus on), but be merely a globally unique identifier. My view would be that the most sensible approach for this would be using URNs (or Uniform Resource Names), which are basically like WWW-style URLs but don't specify *where* a certain resource is to be found. For example, we could agree on a syntax like urn:abc-id:collection:collection-dependent-part like, for example, urn:abc-id:skye-coll:miller_of_drone There would have to be a registry for collections to ensure that the collection names remain globally unique; of course a collection would not have to refer to an actual published volume of tunes, but we could have urn:abc-id:campin:... and so on, where each owner of a collection would be free to make up their collection-dependent-parts (within the confines of URN syntax). This could of course contain an informal classification. The nice thing about this approach is that as URN usage becomes more widespread there could be a `resolving service' accessible to WWW browsers and such that would map abc-id URNs to actual URLs where the resource (i.e., tune) could be found. Of course use of this would not be mandatory; indeed it would not be mandatory for tunes to be actually available on-line. If this idea catches on we should try and get a URN namespace registered with the IANA. And the main problem will still not be solved, that nobody can stop people from stripping off all this usefull information when copying the source. Besides this there is a big problem with altered files in general: If I change the apperance of the abc text - like I do it regulary - whose file is it then, if I correct or alter the abc text - the music - what happens then ? This is difficult to get right. There could be various transformations of an ABC text that would change the bytes of the text but would leave the musical contents as well as the `meta-data' (the title, composer and so on) unchanged. In my opinion, if somebody assigns an URN to a piece of ABC text that means that he or she `signed off' on it as it stands, and that it should be passed on either verbatim or without that URN. If a piece of ABC text is changed then the URN of the `original' could be preserved in a header line. Anselm -- Anselm Lingnau .. [EMAIL PROTECTED] Dost thou love life? Then do not squander time; for that's the stuff life is made of. -- Benjamin Franklin To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] RE: ABC transcrivers ID
I remember fantasising, a couple of years ago, about a usenet-style network of intercommunicating, self-updating abc tune-servers. To avoid the necessity of having a grand guru or an Abc office center authorizing personnal identification number, I propose we could think of a logical code deriving from our country, area, and /or town etc. For the countries we could use a number, like those used in Isbn book code, but it's not really speaking, so we could use the internet code or the classification used in genealogy. for the country we have : http://www.geneanet.com/countrycode.php3?lang=fr (links to regional code for some countries) and for regions in France : http://www.geneanet.com/genealogie/fr/countrycode/country/FRA In canada and Usa : http://www.geocities.com/Heartland/Meadows/3699/gen_form.html So I come from France, Champagne (Aube). My code could begin like that : FRA.CHA.10 I may also add the first letters of my town, or the postal code : Fra.Cha.10.Tro The problem is for huge town, with several abcusers. Why not adding the first letters of the name ? Fra.Cha.10.Tro.For But it's quite a long code. Personally I don't think it's a good idea to use this code in the X: field, because some programs get upset with this (for example a %text is removed after saving tune if it is on the X: line in AbcMus). The Z: field is for the transcriver, so we ought to use it. In an other hand, increasing the X:number to a 8 number code could be a good idea, for identifing volumes, music style etc. in an abc collection. ___ Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr ! Yahoo! Courrier : http://fr.mail.yahoo.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE: ABC transcrivers ID
On Sun, 2 Sep 2001, [iso-8859-1] Forgeot Eric wrote: I remember fantasising, a couple of years ago, about a usenet-style network of intercommunicating, self-updating abc tune-servers. To avoid the necessity of having a grand guru or an Abc office center authorizing personnal identification number, I propose we could think of a logical code deriving from our country, area, and /or town etc. For the countries we could use a number, like those used in Isbn book code, but it's not really speaking, so we could use the internet code or the classification used in genealogy. for the country we have : http://www.geneanet.com/countrycode.php3?lang=fr (links to regional code for some countries) and for regions in France : http://www.geneanet.com/genealogie/fr/countrycode/country/FRA In canada and Usa : http://www.geocities.com/Heartland/Meadows/3699/gen_form.html So I come from France, Champagne (Aube). My code could begin like that : FRA.CHA.10 I may also add the first letters of my town, or the postal code : Fra.Cha.10.Tro The problem is for huge town, with several abcusers. Why not adding the first letters of the name ? Fra.Cha.10.Tro.For But it's quite a long code. Yes, it is. I like the anology with Usenet message-ids - a machine-name is already unique across the internet, so why not use that ? And the only other thing that's needed is a unique number (or other ID) for each tune on that machine. Personally I don't think it's a good idea to use this code in the X: field, because some programs get upset with this (for example a %text is removed after saving tune if it is on the X: line in AbcMus). I agree. Since already exists, inventing new uses for it is likely to create conflict with existing software ... The Z: field is for the transcriver, so we ought to use it. In an other hand, increasing the X:number to a 8 number code could be a good idea, for identifing volumes, music style etc. in an abc collection. ... and likewise with Z: - a magic word uniquely identifying a tune is not the same thing as the name of the person who transcribed that tune. And again likewise, inventing new meanings for an X: number is fine for whoever invents (and implements) them, but strange things might happen when it meets other peoples' software. I dunno. Personally, since I need such a numbering scheme, I'm using a %%ID: line, on the grounds that it won't conflict with any accepted usages; and when I get that sorted out and it reaches my web-collection I'll use another such '%%' line for the 'base' collection, or maybe (probably) to form a URL. Such a scheme will never be more than one person's particular addition unless the writers of the software in use choose to incorporate it. Even then there's always the John Chambers Case - people who read ABC directly and can't even be bothered to include an X: line :- but we can't do anything about that :) -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
