27 Apr 2012 09:00
(no subject)
_______________________________________________ cc-metadata mailing list metadata@... http://lists.ibiblio.org/mailman/listinfo/cc-metadata
_______________________________________________ cc-metadata mailing list metadata@... http://lists.ibiblio.org/mailman/listinfo/cc-metadata
Thanks for the excellent tutorial at http://wiki.creativecommons.org/Single_click_donations_with_CiviCRM I wonder if there has been any discussion of kicking this upstream, to CiviCRM? It would have saved me hours of work :) Before I realized someone must have done this before me. Micheas
On Fri, Jan 14, 2011 at 11:08 PM, Alan Ruttenberg <alanruttenberg@...> wrote: > On Wed, Jan 12, 2011 at 6:36 PM, Nathan Yergler > <nathan@...> wrote: >> The CC license deeds are available in many languages, and users >> sometimes link to the language-specific deed (ie, >> http://creativecommons.org/licenses/by/3.0/deed.es). We want to ensure >> that we're publishing RDFa describing the license itself, and not a >> translation. We also want to make sure agents can follow their nose >> from the translation to the actual license. The question we're trying >> to answer is what predicates to use to model that translation >> relationship. Things I've looked at: >> >> * Dublin Core doesn't seem to have anything translation-specific >> (although hasVersion/isVersionOf -- >> http://www.dublincore.org/documents/dcmi-terms/#terms-hasVersion -- >> looks like it'd be a reasonable generic approach, or something to >> refine if we do our own). >> >> * One instantiation of the FRBR model, >> http://vocab.org/frbr/core.html, includes translation and >> translationOf predicates >> (http://vocab.org/frbr/core.html#translation). This would imply the >> Licenses are "creative or artistic endeavors". > > Yes. However in their interpretation, an intellectual creation is a > "creative or artistic endeavor", as #Work is defined as: "A class > whose members are an abstract notion of an artistic or intellectual > creation.", and work is a subclass of #Endeavor: "A class whose > members are any of the products of artistic or creative endeavour." > > This is not an official version of FRBR by the people who created > FRBR, and there are others > (http://kcoyle.blogspot.com/2007/12/interpretations-of-frbr-classes.html, > http://code.google.com/p/frbr-dl/source/browse/trunk/ontology/2010-10-20-frbr.owl) > . I don't know if there is an official one. It isn't particularly well I don't think there's an official one. While I'm not a FRBR expert by any stretch, my understanding is that it only defines a set of requirements and abstract model, without mandating an actual concrete implementation/model. Seems like we could do a lot worse than either this FRBR core or extended implementation. > stated - for instance I'm not sure that FRBR people would consider > Works to be "notions", and the definition of endeavor is circular. > Endeavor is added by the developers - it is not part of the published > FRBR. > > In any case, if you were to use something from that I would use the > extended http://vocab.org/frbr/extended.html#isATranslationOfExpression > which is less encumbered - it directly relates expressions of the same > work. In this interpretation the "Work" is something like the idea of > of the license elements independent of a particular language, and each > language specific deed is an Expression. > > One thing I would make sure of - is that the translations are of the > same port. It's not clear to me that different jurisdiction ports > should be consider expressions of the same work. In any case the > relation between different ports is not the same as the relation > between different translations of the same port. Naturally. We're only making the assertions about the deed translations for a specific license. > >> >> Is anyone aware of something that's "obviously" the right thing to use? > > I'm not. > >> Any opinions on the above options? > > isATranslationOfExpression seems reasonably on the mark. However it > gets a single google hit, and 0 sindice hits. > http://vocab.org/frbr/core.html#translation doesn't fare any better. > Thanks for the feedback. I think we're going to start with the FRBR vocabulary and work from there as we get feedback. NRY > I like better the idea of extending hasVersion. hasVersion at least > gets a few thousand hits in Sindice (http://tinyurl.com/6edomop) > I would define a subproperty that expressly related translations of > deeds and document the standard by which the translation is made by > CC. > If someone comes up with a standardly used translation relation > between hasVersion and ours we can add it as superproperty. > > -Alan >
The CC license deeds are available in many languages, and users sometimes link to the language-specific deed (ie, http://creativecommons.org/licenses/by/3.0/deed.es). We want to ensure that we're publishing RDFa describing the license itself, and not a translation. We also want to make sure agents can follow their nose from the translation to the actual license. The question we're trying to answer is what predicates to use to model that translation relationship. Things I've looked at: * Dublin Core doesn't seem to have anything translation-specific (although hasVersion/isVersionOf -- http://www.dublincore.org/documents/dcmi-terms/#terms-hasVersion -- looks like it'd be a reasonable generic approach, or something to refine if we do our own). * One instantiation of the FRBR model, http://vocab.org/frbr/core.html, includes translation and translationOf predicates (http://vocab.org/frbr/core.html#translation). This would imply the Licenses are "creative or artistic endeavors". Is anyone aware of something that's "obviously" the right thing to use? Any opinions on the above options? Thanks, NRY
Two small changes have been suggested to CC REL, which I'm planning to make unless issues are raised. They are: 1) make cc:morePermissions refine dct:relation (http://dublincore.org/documents/dcmi-terms/#terms-relation) 2) make cc:License refine dct:LicenseDocument (http://dublincore.org/documents/dcmi-terms/#classes-LicenseDocument) I think both of these are non-controversial, open to feedback on why we shouldn't do this. NRY
We've published a draft of the XHTML+RDFa we'll be generating for Public Domain Mark. You can find information at http://labs.creativecommons.org/2010/08/19/draft-metadata-for-public-domain-mark/. Feedback, comments, suggestions welcome. Nathan
I want to be able to embed CC licences[0] in PDFs made via LaTeX. I'm using xmpincl[1] to embed a licence which works great. I can embed the included example licence of CC-GNU GPL listed in the "The XMP inclusion package" document[2]. But I want to embed a different licence so I need the corresponding XMP file. Many pages on the creative commons site, for example the one on XMP[3] and the one on XMP embedding for pdflatex[4], say that the licensing process[5] offers an XMP template. I can't find this option either before or after the licence is generated. However, there is trick to get the XMP file. Select the licence you want, for example: Allow commercial uses of your work? Yes Allow modifications of your work? No Jurisdiction of your licence: None of the above Additional information Tell us the format of your work: Text Title of work: FIXME_TITLE_OF_WORK Attribute work to name: FIXME_ATTRIBUTE_WORK_TO_NAME Attribute work to URL: FIXME_ATTRIBUTE_WORK_TO_URL Source work URL: FIXME_SOURCE_WORK_URL More permissions URL: FIXME_MORE_PERMISSIONS_URL Click "Select a Licence". This loads a long URL[6]. Now change "results-one" to "xmp" in the URL[7]. This new URL will load "CC_Attribution-No_Derivative_Works_3.0_Unported.xmp". This XMP file contains nothing from, and is not influenced by, the "Additional information" section of the "Choose a License" page[5] so you get same result from missing it out[8]. Now this XMP doesn't include all the elements that are in CC-GNU GPL XMP listed in the "The XMP inclusion package" document[2]. It doesn't have any "Agent" elements nor does it have any "permits" or "requires" elements. I can use hyperref (and beamer) to set Agent-like information in the PDF. Another source of machine readable licences is the RDF versions of licences that are part of cctools[9]. These include an RDF version of "CC_Attribution-No_Derivative_Works_3.0_Unported"[10]. These RDF licences include elements of "permits", "requires" and the "title" in many languages other than English. These elements are not in the XMP file obtained from the "Choose a License" page[5]. Could this be because it is using an older, simpler schema as described in "Embedded Metadata with XMP"[11] that has now be extended to the current schema[12]? Given all this, is the XMP file generated via the "Choose a Licence" method[8] sufficient to convey the licence? And if not, then what XMP file should I use? Your advice is very much appreciated. Please note that I am not subscribed to the list so please CC me. Regards, Michael. [0] British English spelling. [1] http://www.ctan.org/tex-archive/macros/latex/contrib/xmpincl/ [2] http://mirror.ctan.org/macros/latex/contrib/xmpincl/xmpincl.pdf [3] http://wiki.creativecommons.org/XMP [4] http://creativecommons.org/weblog/entry/4270 [5] http://creativecommons.org/choose/ [6] http://creativecommons.org/choose/results-one?q_1=2&q_1=1&field_commercial=yes&field_derivatives=n&field_jurisdiction=&field_format=Text&field_worktitle=FIXME_TITLE_OF_WORK&field_attribute_to_name=FIXME_ATTRIBUTE_WORK_TO_NAME&field_attribute_to_url=FIXME_ATTRIBUTE_WORK_TO_URL&field_sourceurl=FIXME_SOURCE_WORK_URL&field_morepermissionsurl=FIXME_MORE_PERMISSIONS_URL&lang=en_GB&language=en_GB&n_questions=3 [7] http://creativecommons.org/choose/xmp?q_1=2&q_1=1&field_commercial=yes&field_derivatives=n&field_jurisdiction=&field_format=Text&field_worktitle=FIXME_TITLE_OF_WORK&field_attribute_to_name=FIXME_ATTRIBUTE_WORK_TO_NAME&field_attribute_to_url=FIXME_ATTRIBUTE_WORK_TO_URL&field_sourceurl=FIXME_SOURCE_WORK_URL&field_morepermissionsurl=FIXME_MORE_PERMISSIONS_URL&lang=en_GB&language=en_GB&n_questions=3 [8] http://creativecommons.org/choose/xmp?q_1=2&q_1=1&field_commercial=yes&field_derivatives=n&field_jurisdiction=&lang=en_GB&language=en_GB&n_questions=3 [9] http://cctools.svn.sourceforge.net/viewvc/cctools/license.rdf/trunk/license_rdf/ [10] http://cctools.svn.sourceforge.net/viewvc/cctools/license.rdf/trunk/license_rdf/creativecommons.org_licenses_by-nd_3.0_.rdf [11] http://wiki.creativecommons.org/images/f/ff/Creativecommons-embedded-metadata-with-xmp_eng.pdf [12] http://creativecommons.org/ns#
Dear all, we are working on re-specifying the integration of the ccREL ontology into the mathematical markup language OMDoc (http://www.omdoc.org) in a more formal way. Now I wonder: Is there any way of saying that some Permission does _not_ hold (e.g. that distribution is not permitted, or should I rather say "prohibited"?), or that some Prohibition does not hold (e.g. that commercial use is not prohibited, or should I rather say "permitted"?) ? XY cc:permits cc:CommercialUse is not really intended by the current implementation of the ccREL ontology. So do you rather assume negation as failure? I.e. that if "XY cc:prohibits cc:CommercialUse" is _not_ explicitly mentioned, then we assume that commercial use is not prohibited? But, if so, wouldn't that conflict with the open world nature of RDFS? Thanks in advance for any hints, Christoph -- -- Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701
_______________________________________________ cc-metadata mailing list metadata@... http://lists.ibiblio.org/mailman/listinfo/cc-metadata
Many of you I hope! Please share http://creativecommons.org/weblog/entry/15095 encouraging people to attend the CC Tech Summit and COMMUNIA conference later this month. Registration deadlines approaching. Thanks, Mike p.s. Click on "CC BY-SA" in the photo caption on http://creativecommons.org/weblog/entry/15095 to see ccREL in action on the license deed -- attribution info and copy&paste HTML is auto-populated from the photo's license metadata.
_______________________________________________ cc-metadata mailing list metadata@... http://lists.ibiblio.org/mailman/listinfo/cc-metadata
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
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 |