Discussion:
[cc-devel] cc-devel Digest, Vol 99, Issue 1
kyaw thura maung
2015-03-12 20:45:31 UTC
Permalink
Send cc-devel mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ibiblio.org/mailman/listinfo/cc-devel
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cc-devel digest..."
1. Fwd: [cc-staff] CC is hiring - seeking software developer
(Matt Lee)
2. Re: We'd like your feedback on our proposed new contributor
agreement for The List app (Ben Finney)
3. ccREL question (Maarten Zeinstra)
4. Re: ccREL question (Mike Linksvayer)
5. Re: ccREL question (Maarten Zeinstra)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Jan 2015 17:40:49 -0500
Subject: [cc-devel] Fwd: [cc-staff] CC is hiring - seeking software
developer
<
<javascript:;>>
Content-Type: text/plain; charset=UTF-8
Come work with me :)
---
Matt Lee
Creative Commons
Boston, MA, USA
---------- Forwarded message ----------
<javascript:;>>
Date: Wed, Jan 28, 2015 at 5:33 PM
Subject: [cc-staff] CC is hiring - seeking software developer
Hello friends of CC,
We're doubling the size of of development team! With the generous
support of the Hewlett Foundation, we'll be hiring a second developer
at CC to work on one of our core 2015 strategic goals: improved
discovery, curation, use and re-use of the commons.
Please help us in our search by taking 2 minutes right now to share
our post in your networks on social, or to forward this e-mail to
someone you know who would like to join our team.
http://creativecommons.org/weblog/entry/44802
Thanks,
Ryan
New job at CC: Software developer
Matt Lee, January 28th, 2015
Today, we?re opening up a new job posting, for a developer. This
person will work with our education team and existing technical lead
to develop tools that facilitate the discovery, curation, use and
re-use of freely available online content.
The developer?s tasks will include the development of an online
catalog of open education resource (OER) materials to facilitate
discovery, curation, use and re-use, and content analytics. We?re
really excited about this project, which will most certainly have
applications across the commons.
Creative Commons is a global nonprofit organization focused on
enabling the open commons of knowledge to grow and flourish. Our work
crosses multiple sectors of creativity and knowledge ? from
photography, to music, to open educational resources, copyright
reform, and open data. Today the commons includes over 880 million
CC-licensed works, and we expect to pass 1 billion works in 2015.
Are you excited about powering the technical infrastructure of
Creative Commons? Learn more and apply.
--
Ryan Merkley
CEO, Creative Commons
+1 416.802.0662
@ryanmerkley
Please make a donation: https://donate.creativecommons.org
_______________________________________________
cc-staff mailing list
------------------------------
Message: 2
Date: Wed, 04 Feb 2015 19:09:22 +1100
Subject: Re: [cc-devel] We'd like your feedback on our proposed new
contributor agreement for The List app
Content-Type: text/plain; charset=utf-8
The List is a new web app and Android app from Creative Commons. We're
developing it in the open, under a free software license. We'd like to
get third party contributions, and we have an agreement that we're
proposing that'll do that.
Please don't ask for a unilateral copyright assignment; not even a
?licensing agreement? of this kind. It is hostile to the level field
normally created by free licensing.
Instead, please just require that the work is licensed under the same
license your organisation will be granting (?inbound = outbound?).
More explanation of why CLAs are not desirable is at
<URL:http://www.ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html>.
--
\ ?What I have to do is see, at any rate, that I do not lend |
`\ myself to the wrong which I condemn.? ?Henry Thoreau, _Civil |
_o__) Disobedience_ |
Ben Finney
------------------------------
Message: 3
Date: Mon, 9 Mar 2015 13:34:31 +0100
Subject: [cc-devel] ccREL question
Content-Type: text/plain; charset="utf-8"
Hi all,
I am working with a collections of international heritage institutions
(Europeana and DPLA) that wants to make a clearer classification of in
copyright right works. Basically we want to create a neutral namespace
based on the Europeana Rights Statements (
http://pro.europeana.eu/share-your-data/rights-statement-guidelines/available-rights-statements
<
http://pro.europeana.eu/share-your-data/rights-statement-guidelines/available-rights-statements>).
Mapping this space of restrictions helps re-users find the niches in which
they still use the tagged works and know when works will become available
for re-use.
The group is now designing the underlying metadata of these rights
statements and are researching the use of ccREL. They have some trouble
with the definition of cc:License. Included below I paraphrase their
critique. I?m wondering if there is still anyone on this list that can
provide some valuable feedback on this.
[..] cc:License really strongly hints at "real" licenses, while CC has a
broader interpretation ("a set of requests/permissions to users of a Work,
e.g. a copyright license, the public domain, information for
distributors?.) and uses it also for Public Domain Mark (
https://github.com/creativecommons/license.rdf/tree/master/cc/licenserdf/licenses
<
https://github.com/creativecommons/license.rdf/tree/master/cc/licenserdf/licenses>,
PDM at
https://github.com/creativecommons/license.rdf/blob/master/cc/licenserdf/licenses/creativecommons.org_publicdomain_mark_1.0_.rdf
<
https://github.com/creativecommons/license.rdf/blob/master/cc/licenserdf/licenses/creativecommons.org_publicdomain_mark_1.0_.rdf
)
This may make the choice of cc:License less natural for our audience of
data providers and re-users.
The CC REL RDFS <http://creativecommons.org/schema.rdf> is also a bit
contradictory, as cc:License is described as a subclass of
dmci:LicenseDocument, which feel wrong because dmci:LicenseDocument seems
more restrictive than cc:License (cc:License should just be a subclass or
equivalent class to dcmi:RightsStatement)
We sense that dcterms:RightsStatements is a better fit, but want to
clarify ccREL approach.
ODRL uses odrl:Policy (
https://www.w3.org/community/odrl/model/2.1/#section-2 <
https://www.w3.org/community/odrl/model/2.1/#section-2>)
ODRS uses odrs:RightsStatement. Interestingly ODRS de-couple statements
from license, i.e. it seems that in most case one needs one instance of
each class, see
https://github.com/theodi/open-data-licensing/blob/master/guides/publisher-guide.md
<
https://github.com/theodi/open-data-licensing/blob/master/guides/publisher-guide.md
)
What does the list suggest we do in this project? Should we adopt
CC:License or is it better to use odrs:RightsStatement or odrl:policy?
Cheers,
Maarten Zeinstra
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.ibiblio.org/pipermail/cc-devel/attachments/20150309/a7f73208/attachment-0001.html
------------------------------
Message: 4
Date: Tue, 10 Mar 2015 21:56:38 -0700
Subject: Re: [cc-devel] ccREL question
Content-Type: text/plain; charset=windows-1252
What does the list suggest we do in this project? Should we adopt
CC:License or is it better to use odrs:RightsStatement or odrl:policy?
dcterms:RightsStatement
IIRC CC stuck with license/License for PDM when that was introduced so
that the (mostly theoretical, and likely doing regexps on a page rather
than parsing RDF) consumer would not have to know about another
property/class. But arguably CC REL ought have been (or ought be still)
updated such that cc:license is a subproperty of dcterms:rights rather
than dcterms:license and cc:License a subclass of
dcterms:RightsStatement rather than dcterms:LicenseDocument.
Again IIRC dcterms:RightsStatement and LicenseDocument did not exist
until 2008. Had they existed in 2002, I guess the vocabulary CC
introduced (later branded as CC REL) would have used one of them
directly rather than introducing cc:License. Which brings us back to the
answer to your question.
Mike
p.s. I'm using dcterms: for precision and because I note the EDM
document does, though one of my super tiny pet peeves
<http://gondwanaland.com/mlog/2014/02/04/one-dc/> concerns never using
DCES 1.1 for anything (all its terms are mirrored in dcterms) and thus
only/always using dc: prefix for http://purl.org/dc/terms/
------------------------------
Message: 5
Date: Thu, 12 Mar 2015 16:31:14 +0100
Subject: Re: [cc-devel] ccREL question
Content-Type: text/plain; charset=us-ascii
Thanks Mike!
So you would actually advise not using the CC:License term in this case?
Also a more general comment towards the CC Global. Do you have any
interest in structurally pushing/updating CCrel or is it in your interests
to not further that data standard?
Cheers,
Maarten
--
What does the list suggest we do in this project? Should we adopt
CC:License or is it better to use odrs:RightsStatement or odrl:policy?
dcterms:RightsStatement
IIRC CC stuck with license/License for PDM when that was introduced so
that the (mostly theoretical, and likely doing regexps on a page rather
than parsing RDF) consumer would not have to know about another
property/class. But arguably CC REL ought have been (or ought be still)
updated such that cc:license is a subproperty of dcterms:rights rather
than dcterms:license and cc:License a subclass of
dcterms:RightsStatement rather than dcterms:LicenseDocument.
Again IIRC dcterms:RightsStatement and LicenseDocument did not exist
until 2008. Had they existed in 2002, I guess the vocabulary CC
introduced (later branded as CC REL) would have used one of them
directly rather than introducing cc:License. Which brings us back to the
answer to your question.
Mike
p.s. I'm using dcterms: for precision and because I note the EDM
document does, though one of my super tiny pet peeves
<http://gondwanaland.com/mlog/2014/02/04/one-dc/> concerns never using
DCES 1.1 for anything (all its terms are mirrored in dcterms) and thus
only/always using dc: prefix for http://purl.org/dc/terms/
_______________________________________________
cc-devel mailing list
http://lists.ibiblio.org/mailman/listinfo/cc-devel
------------------------------
Subject: Digest Footer
_______________________________________________
cc-devel mailing list
http://lists.ibiblio.org/mailman/listinfo/cc-devel
------------------------------
End of cc-devel Digest, Vol 99, Issue 1
***************************************
--
Kyaw
Loading...