I'm with a group that is going to adopt rules of order. We'd prefer not to shell out $15 or so for a copies of Roberts Rulse. Anyone know of any public domain or Creative Commons alternatives? -- -- Matthew Saroff "A modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness." -- John Kenneth Galbraith
Creative Commons has long had standard methods for embedding license information in MP3 and OGG audio files. As we begin to work on a "libcc" or similar library, we probably need to discuss best practices for embedding in other common formats. The one that matters to me today is JPEG, so I wanted to outline a couple of options and get feedback or consensus. It seems there are two obvious possiblities for embedding CC license information in JPEG files. First, EXIF contains a "copyright" tag which is intended to be populated with a statement such as "Copyright, John Smith, 20xx. All rights reserved." Following the example of embedding a license statement in the TCOP field of ID3v2 for MP3 files, we could embed a standard statement, such as "© 1995 Example Photographer. Licensed to the public under http://creativcommons.org/licenses/by/2.0/ verify at http://example.com/licenseinfo". Work metadata and verification information would then be stored in an external file, in this case http://example.com/licenseinfo. This approach has the advantages that EXIF manipulation is well understood and a common operation of image editting software and sites. Additionally, other tools may be able to display CC license metadata (even if they do not validate or populate) simply because they display all available EXIF data. However, the disadvantage is that it requires metadata to be stored in an external, secondary file. The other semi-obvious choice that comes to mind is using Adobe XMP metadata (http://www.adobe.com/products/xmp/). CC already provides a specification and instructions for using XMP metadata in Adobe applications such as Photoshop (http://creativecommons.org/technology/xmp-help) and Adobe provides an(Continue reading)
Mike and I spoke about this yesterday afternoon and came to the conclusion that we really need to support both EXIF and XMP embedding. They both have interested audiences, and we can probably leverage them better by supporting both approaches independently or simultaneously. The CC XMP specification (http://creativecommons.org/technology/xmp) already lays out two possible formats for the Copyright field, which are minor distinctions upon what Christopher suggested. In particular they omit the copyright owner, presumably because XMP (and EXIF) provides other tags which are more appropriate for that information. The two possibly formats for the copyright statement are: This work is licensed to the public under the Creative Commons Attribution-ShareAlike license http://creativecommons.org/licenses/by-sa/2.0/ and This work is licensed to the public under the Creative Commons Attribution-ShareAlike license http://creativecommons.org/licenses/by-sa/2.0/ verify at http://example.com/metadata.html The difference being the "verify at [URL]" statement at the end of the statement. The proposal is that either format will be considered valid. This allows users to make statements about the license without having to use verification RDF. Unless there are objections or further refinements people would like to see, I'll write up a specification page using this format.(Continue reading)
Christopher Allen wrote: > EXIF is very similar to TCOP in MP3, and ICOP in MP2/4, so I lean toward > supporting in audio and video. I do recommend a slight modifier of how the > text should read: > > Instead of: > > C 1995 Example Photographer. Licensed to the public under > http://creativcommons.org/licenses/by/2.0/ verify at > http://example.com/licenseinfo > > C 2005 Example Photographer <email@...> -- This work is licensed to > the public under the Creative Commons Attribution-NonCommercial-ShareAlike > License http://creativecommons.org/licenses/by-nc-sa/2.5/ verify at > http://example.com/licenseinfo Everything before "license-url [verify at metadata-url]" is for humans only and can be as verbose as you like. We should be explicit about this. Currently http://creativecommons.org/technology/mp3 only explicitly says # If "verify at " exists in TCOP, everything after it must be the # license claim URL, and if there is a license claim URL then it must be # preceded by "verify at ". The first formulation above was designed to keep the string as short as possible while still providing useful information to humans given programs that display the contents of TCOP and similar are obviously expecting something much shorter, rendering such fields in short single(Continue reading)
On Tuesday, August 02, 2005 11:45 AM Mike Linksvayer <> wrote: >> Instead of: >> >> C 1995 Example Photographer. Licensed to the public under >> http://creativcommons.org/licenses/by/2.0/ verify at >> http://example.com/licenseinfo >> >> C 2005 Example Photographer <email@...> -- This work is >> licensed to the public under the Creative Commons >> Attribution-NonCommercial-ShareAlike >> License http://creativecommons.org/licenses/by-nc-sa/2.5/ verify at >> http://example.com/licenseinfo > > Everything before "license-url [verify at metadata-url]" is for > humans only and can be as verbose as you like. We should be explicit > about this. Currently http://creativecommons.org/technology/mp3 only > explicitly says > > # If "verify at " exists in TCOP, everything after it must be the # > license claim URL, and if there is a license claim URL then it must > be # preceded by "verify at ". > > The first formulation above was designed to keep the string as short > as possible while still providing useful information to humans given > programs that display the contents of TCOP and similar are obviously > expecting something much shorter, rendering such fields in short > single line widgets. I see nothing wrong with being more verbose, > nor any reason to require a specific format for that part of the > string.(Continue reading)
Conrad Parker wrote: > sorry if this is the wrong place to report this :) > > just looking around the wiki, it appears the following pages are > similar: > > http://wiki.creativecommons.org/wiki/Share_Alike > http://wiki.creativecommons.org/wiki/Sharealike > > Both are listed on the Popular Pages special page. I guess it would > make sense to merge the content and make one a redirect to the other. > I'm new here so I'll leave that to whoever's appropriate to do it :) Wrong place, but there isn't any established place. Going forward, follow the example of http://en.wikipedia.org/wiki/Wikipedia:Duplicate_articles and use http://wiki.creativecommons.org/wiki/CreativeCommons:Duplicate_articles -- -- Mike Linksvayer http://creativecommons.org/about/people#21
>>>BTW, some of the logic on why the text: >>> >>>I explicitly wanted there to be some ability to contact the author of the >>>work, either email or web page. The statement "This work is licensed to the >>>public" is licensed to be clear that we are talking about what the item is >>>(this work) and that this is the public license, not a private license (for >>>instance, Magnatune has CC licensed music files and high-bitrate music files >>>that are only licensed to individuals). I felt naming the license was >>>important for human readibility. The rest kept compatibility with the >>>existing examples. >>> >>> I like these improvements a lot. I'd like to suggest one tweak --have the contact info be a URL instead of an email address. Few people are willing to put an email address that they check regularly into a public document, and a URL allows for stuff like the phone number of your management.
Lucas Gonze wrote: > I'd like to suggest one tweak --have the contact info be a URL instead > of an email address. Few people are willing to put an email address > that they check regularly into a public document, and a URL allows for > stuff like the phone number of your management. I agree regarding URL rather than email, but the "verify at" URL is intended to provide useful info for humans as well as metadata. Put in the crassest possible manner: http://creativecommons.org/technology/embedding#3 -- -- Mike Linksvayer http://creativecommons.org/about/people#21
Mike Linksvayer wrote: >Lucas Gonze wrote: > > >>I'd like to suggest one tweak --have the contact info be a URL instead >>of an email address. Few people are willing to put an email address >>that they check regularly into a public document, and a URL allows for >>stuff like the phone number of your management. >> >> > >I agree regarding URL rather than email, but the "verify at" URL is >intended to provide useful info for humans as well as metadata. Put in >the crassest possible manner: >http://creativecommons.org/technology/embedding#3 > > What's standard practice right now? Are users pointing to the boilerplate page, or are they pointing to custom pages which contain contact info? I'd bet they're pointing to the boilerplate page, which suggests to me that a web service to edit and maintain custom pages (with contact info) would be a win. - Lucas
>> > What's standard practice right now? Are users pointing to the > boilerplate page, or are they pointing to custom pages which contain > contact info? I'd bet they're pointing to the boilerplate page, which > suggests to me that a web service to edit and maintain custom pages > (with contact info) would be a win. What do you mean by "boilerplate page"? Do you mean a page on their site that only includes the license information? Verify links by definition have to reside on a site the user has control of, since they contain SHA1 hashes of the specific file for verification purposes. NRY > > - Lucas > > _______________________________________________ > cc-metadata mailing list > metadata@... > http://lists.ibiblio.org/mailman/listinfo/cc-metadata >
RSS Feed1 | |
|---|---|
1 | |
1 | |
3 | |
1 | |
1 | |
3 | |
1 | |
3 | |
1 | |
5 | |
3 | |
1 | |
1 | |
1 | |
1 | |
3 | |
5 | |
1 | |
8 | |
6 | |
34 | |
19 | |
6 | |
17 | |
8 | |
15 | |
4 | |
8 | |
23 | |
2 | |
5 | |
19 | |
46 | |
1 | |
12 | |
40 | |
7 |
