Skip to Content.
Sympa Menu

cc-devel - Re: [cc-devel] CC 1.5 and embedding RDF

cc-devel AT lists.ibiblio.org

Subject: Developer discussion for Creative Commons technology and tools

List archive

Chronological Thread  
  • From: Nathan Yergler <nathan AT creativecommons.org>
  • To: Wendy Bossons <wbossons AT mit.edu>
  • Cc: cc-devel AT lists.ibiblio.org
  • Subject: Re: [cc-devel] CC 1.5 and embedding RDF
  • Date: Mon, 7 Dec 2009 10:44:32 -0800

Right, although in the second case, you don't even need the xmlns:cc
attribute.

Nathan


On Mon, Dec 7, 2009 at 8:38 AM, Wendy Bossons <wbossons AT mit.edu> wrote:
> So then either of the following are correct (first example is from the given
> w3 page), but the unprefixed form is safer in the sense that it's more
> likely to be understood by a wide range of search engines . . .
>
> <a xmlns:cc="http://creativecommons.org/ns#";
> rel="cc:license"
> href="http://creativecommons.org/licenses/by-nc-nd/3.0/";>
> Creative Commons License
> </a>
>
> or
>
> <a xmlns:cc="http://creativecommons.org/ns#";
> rel="license"
> href="http://creativecommons.org/licenses/by-nc-nd/3.0/";>
> Creative Commons License
> </a>
>
>
>
> Wendy Bossons
> Web Developer
> Contact Information:
> wbossons AT mit.edu
> 617-253-0770
>
>
>
>
>
> On Dec 7, 2009, at 10:28 AM, Nathan Yergler wrote:
>
> license is one of the reserved values in RDFa, as it's defined in the
> XHTML namespace; see http://www.w3.org/TR/rdfa-syntax/#relValues for a
> list of these values.  It's implicit that license is in the XHTML
> namespace, and any conforming RDFa processor will return a fully
> qualified URI in that namespace.
>
> You could do cc:license, but these days it's declared to be the same
> of xhtml:license.  Additionally, it appears that some search engines
> do not use conforming processors to index CC licensed content, instead
> looking for rel="license", so using a different namespace will impact
> how they index your content.
>
> Nathan
>
>
> On Mon, Dec 7, 2009 at 7:21 AM, Wendy Bossons <wbossons AT mit.edu> wrote:
>
> Why is the metainformation attribute, rel, never prefixed when it references
>
> "license"?
>
> Example:
>
> <a rel="license"
>
> href="http://creativecommons.org/licenses/by/3.0/us/";>......</a>
>
> Would it be incorrect to rephrase the above as:
>
> <a rel="cc:license" xmlns:cc="http://creativecommons.org/ns#";
>
> href="http://creativecommons.org/licenses/....";>.......</a>
>
> The reason I ask is the CC LIcense searchable as metadata within the
>
> application I'm working on. If it is to do that, I believe the license
>
> metadata should follow the same pattern as other metadata, such as
>
> <span xmlns:dc="http://purl.org/dc/...."; href="http://purl.org/dc/dmcitype/";
>
> rel="dc:type">work</span>
>
>
> ..\Wendy
>
>
> Wendy Bossons
>
> Web Developer
>
> Contact Information:
>
> wbossons AT mit.edu
>
> 617-253-0770
>
>
>
>
>
>
> On Dec 3, 2009, at 1:38 PM, Nathan Yergler wrote:
>
> Hi Wendy,
>
> The two blocks have (had) slightly different purposes; the first one
>
> describes a work with a particular license.  The latter only describes
>
> the license.
>
> That said, we no longer recommend embedding either in HTML pages.  We
>
> previously recommended embedding the former block in an HTML comment.
>
> While this approach had advantages over other available approaches
>
> when we developed it, it still has lots of problems, including over
>
> verbosity, invisibility to many parsers, and lack of standards
>
> compliance.  We're now recommending the use of RDFa to describe the
>
> license of a page.  See
>
> http://creativecommons.org/choose/results-one?license-code=by for an
>
> example of the HTML+RDFa needed to describe the license of a work, and
>
> http://wiki.creativecommons.org/ccREL for more details.
>
> Let me know if you have any questions.
>
> Nathan
>
>
> On Mon, Nov 30, 2009 at 2:51 PM, Wendy Bossons <wbossons AT mit.edu> wrote:
>
> What is the current recommendation on using the rdf that is returned by
>
> the
>
> CC issue call?
>
> For example, there are two rdf blocks in the response. Is one for
>
> backward
>
> compatibility? How do you recommend using the response, e.g. if embedding
>
> the rdf in the page, should one or both of the rdf blocks be used?
>
> Example from response document:
>
> ...
>
> <rdf>
>
>  <rdf:RDF xmlns="http://creativecommons.org/ns#";
>
> xmlns:dc="http://purl.org/dc/elements/1.1/";
>
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
>
> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#";>
>
>   <Work rdf:about="">
>
>    <license
>
> rdf:resource="http://creativecommons.org/licenses/by/3.0/us/"/>
>
>   </Work>
>
>   <License rdf:about="http://creativecommons.org/licenses/by/3.0/us/";>
>
>    <permits rdf:resource="http://creativecommons.org/ns#Reproduction"/>
>
>    <permits rdf:resource="http://creativecommons.org/ns#Distribution"/>
>
>    <requires rdf:resource="http://creativecommons.org/ns#Notice"/>
>
>    <requires rdf:resource="http://creativecommons.org/ns#Attribution"/>
>
>    <permits
>
> rdf:resource="http://creativecommons.org/ns#DerivativeWorks"/>
>
>   </License>
>
>  </rdf:RDF>
>
> </rdf>
>
> <licenserdf>
>
>  <rdf:RDF xmlns="http://creativecommons.org/ns#";
>
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";>
>
>  <License rdf:about="http://creativecommons.org/licenses/by/3.0/us/";>
>
>    <permits rdf:resource="http://creativecommons.org/ns#Reproduction"/>
>
>    <permits rdf:resource="http://creativecommons.org/ns#Distribution"/>
>
>    <requires rdf:resource="http://creativecommons.org/ns#Notice"/>
>
>    <requires rdf:resource="http://creativecommons.org/ns#Attribution"/>
>
>    <permits
>
> rdf:resource="http://creativecommons.org/ns#DerivativeWorks"/>
>
>  </License>
>
>  </rdf:RDF>
>
> </licenserdf>
>
> Wendy Bossons
>
> Web Developer
>
> Contact Information:
>
> wbossons AT mit.edu
>
> 617-253-0770
>
>
>
>
>
>
> _______________________________________________
>
> cc-devel mailing list
>
> cc-devel AT lists.ibiblio.org
>
> http://lists.ibiblio.org/mailman/listinfo/cc-devel
>
>
>
>
>
>




Archive powered by MHonArc 2.6.24.

Top of Page