Brian | 27 Apr 2012 09:00
Brian | 14 Oct 2011 22:59
Picon
Favicon
Gravatar

Re: 4

Increase your sexual desire! . http://esculta.scoutsdelcarmen.com/com.page.php?oqesiteid=17i0
Micheas Herman | 20 Apr 2011 11:09
Gravatar

Single click donations with CiviCRM

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
Nathan Yergler | 27 Jan 2011 01:57
Gravatar

Re: [cc-tab] Publishing assertions for license translations

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
>
Nathan Yergler | 13 Jan 2011 00:36
Gravatar

Publishing assertions for license translations

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
Nathan Yergler | 4 Oct 2010 20:32
Gravatar

Proposal for two small changes to CC REL

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
Nathan Yergler | 20 Aug 2010 01:09
Gravatar

Draft metadata for Public Domain Mark

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
Michael Dorrington | 2 Mar 2010 20:40
Picon

Obtaining XMP CC licences for embedding in PDFs

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#
Christoph LANGE | 19 Jun 2009 13:08
Picon
Favicon

How to negate cc:permits, cc:prohibits, cc:requires?

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
Mike Linksvayer | 10 Jun 2009 18:37
Gravatar

See you in Torino!

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.
for.arts.sake | 4 May 2009 19:20
Picon
Favicon

Vacation reply

Good day! Thanks for dropping me a line. For the next two weeks, I'll be checking email intermittently, as I'm doing Major Life Change. GeomeKelly and I are finally tying the knot and I'm joining him in the southern United States for first post-degree and then grad school studies. This email address will no longer be used after April 25th. Please update your address book to shirley-NdZvWLXZIRG91MBA64eaIQ@public.gmane.org I'll be back online at this email address May 8th.
Until then, have practice safe surfing, know where your towel is and remember that the answer to all things is "42". - Shirley Hicks
_______________________________________________
cc-metadata mailing list
metadata@...
http://lists.ibiblio.org/mailman/listinfo/cc-metadata

Gmane