When a web site is licensed under Creative Commons, I use the rel-license microformat. When a web site is licensed under regular copyright, I have a boring paragraph element.
<p id="copyright">© 2008 Example Corporation</p>
That id attribute on there is just for CSS styling purposes. I'm wondering if there's some better way to markup a copyright notice that is more semantic. Is this a job for Dublin Core metadata? If so, how do I go about it? (I've never used Dublin Core before.)
Some web sites advocate using a meta tag in the head element:
<meta name="copyright" content="name of owner">
Which might be seen by search engines, but doesn't replace the user-visible notice on the page itself.
Thanks to Owen for pointing me in the direction of RDFa, I think I've got the solution now:
<div id="footer" xmlns:dc="http://purl.org/dc/elements/1.1/">
<p id="copyright" property="dc:rights">©
<span property="dc:dateCopyrighted">2008</span>
<span property="dc:publisher">Example Corporation</span>
</p>
</div>
Depending on the situation, it might be better to use dc:creator instead of dc:publisher. From the Dublin Core web site:
If the Creator and Publisher are the same, do not repeat the name in the Publisher area. If the nature of the responsibility is ambiguous, the recommended practice is to use Publisher for organizations, and Creator for individuals. In cases of lesser or ambiguous responsibility, other than creation, use Contributor.
I will also be adding a meta tag to my head element for search engines that don't support RDFa yet.
<meta name="copyright" content="© 2008 Example Corporation" />
Have you taken a look at RDFa? It was recently accepted as a W3C recommendation. I mention that just in case you want to take a look at other aspects of semantic structure it recommends. The licensing part is the same as the format you currently use. (So in that sense to answer your question, I think you're handling it correctly, assuming people adopt RDFa)
For lazy people who don't want to click links:
// RDFa recomendation and rel=license microformat
<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
a Creative Commons License
</a>
Probably the most semantically correct way to mark it up is with a definition list.
<dl id="copyright">
<dt title="Copyright">©</dt>
<dd>2008 Example Corporation</dd>
</dl>
Why not use the CC format, but indicate that no rights are granted?
In any case, the main problem with the use of the CC formats is that people do not clearly identify which elements of the webpage that they appear on they apply to.
Related
The guidebook written by the Brazilian government regarding good practices in web development recommends using the following meta tags:
<meta name="target_country" content="br" />
<meta name="country" content="Brazil" />
It does not provide any explanation for why we should use them, though. The guidebook is a 10 years old document; there are visibly outdated codes there. However, that was not the case with those two meta tags: I could not find whether they are recommended or deprecated by W3C. I could not even find if they actually exist, to begin with.
Are the meta tags target_country and country useful? If so, what for? Are they endorsed by W3C, or considered a good practice by any other relevant institution, browser, social network etc.? Do they help increasing accessibility?
Short answer
Remove them if allowed, they are not valid and serve no purpose.
Long Answer
These definitely aren't part of the current spec for HTML5, I would guess they are HTML4 (if they were even relevant then, people did like to make up meta tags!)
Over on the wiki I can see that both "country" and "target_country" do not exist.
If you really need to display some form of location data use geo.country or geo.region etc. However Google ignores these anyway. so I am unsure if they have much use.
The only thing that I can think they may have been relevant for was for identifying the language of the page, but in HTML 5 you should be using the lang attribute on the HTML tag anyway.
Forget Brazil for a moment because internet standards apply all over the world. That being said, I have never came across that tag in last 2 decades. Looks like outdated information and you shouldn't be worried about it. If (and it's a Big IF) they have made some kind of crawler or a directory/search engine themselves which does gives priority to this tag then it will be just limited in scope to that crawler/directory/search engine.
<meta name="copyright" content="By Me" />
W3C validator output:
Line 5, Column 41: Bad value copyright for attribute name on element meta: Keyword copyright is not registered.
I need to set the copyright. Any idea?
Dublin Core proposes the rightsHolder term (an extension to the <meta> name attribute), which validates using the W3C HTML5 validator:
<meta name="dcterms.rightsHolder" content="Your Copyright-Holder Organization">
This is defined as A person or organization owning or managing rights over the resource.
Additional terms:
For a statement about property rights, we can use the regular rights term:
<meta name="dcterms.rights" content="Statement of copyright">
To add the date of copyright:
<meta name="dcterms.dateCopyrighted" content="2012">
Source: http://wiki.whatwg.org/wiki/MetaExtensions
Nitpick
According to the MetaExtensions document, all these statements must be accompanied by a special <link> element:
<link rel="schema.dcterms" href="http://purl.org/dc/terms/">
<meta name="dcterms.rightsHolder" content="Your Copyright-Holder Organization">
However, the W3C validator does not enforce this.
TL;DR Most of the non standard meta tags are not yet available for HTML5 validators. Until then you should include a small tag if you must have valid code.
Ok, I did a little bit more research into the subject. The issue is that the metatags on the WHATWG wiki are supposed to be used by validators, but in many cases because the tags update so frequently most validators ignore them until they become official parts of the spec.
So the only standard metatags right now are:
application-name
author
description
generator
keywords
Eventually once the spec gets updated again the rights-standard metatag will validate as well, but until then we need a workaround ... which is ...
....drumroll....
The <small> tag!
The small element represents side comments such as small print.
Small print typically features disclaimers, caveats, legal
restrictions, or copyrights. Small print is also sometimes used for
attribution, or for satisfying licensing requirements.
Source: http://dev.w3.org/html5/spec/text-level-semantics.html#the-small-element
Also, just a side note. Just because your code doesn't validate doesn't mean it isn't valid. The spec is constantly evolving, so you just need to bear with it until things become more concrete.
BACKGROUND
I have been using microformats for the past 5 years. I'm switching to the schema.org approach for all new sites because it's — IMHO — a better separation of style and meta info.
In addition all the major search providers have adopted and now fully support the schema.org approach to microdata.
It's been a pretty painless process finding schema.org equivalents most microdata objects i.e. hCard, hCalendar etc. and am I pleased with the extra possibilities.
QUESTION
I am looking to find clear examples of the markup in the hAtom/hNews (hFeed)
flavour can anyone point me in the right direction/give some tips as
I have searched but been unsuccessful up to now. On schema.org I
don't see a clear equivalent.
We have this handy markup generator http://schema-creator.org/
for; Person, Product, Event, Organization, Movie, Book and Review,
but has anyone seen a tool for the creation of the markup of
schema.org variant of hFeeds.
question 01: Creativeworks -> Blog is schema's equivalent to hatom.
no clue if anyone's used it or written about it yet.
i'd like to know what about schema.org is better at separation of concerns vs. microformats? schema.org has meta elements within the body element. microformats are html classes and and as such natively support separation. also, every major search provider already provided coverage of microformats and it hasn't decreased. curious, i am.
You have to choose a page type, like for example http://schema.org/Blog and then add the article/blogposts http://schema.org/BlogPosting
Here is a very simple example:
<div itemscope itemtype="http://schema.org/Blog">
...
<article itemprop="blogPost" itemscope itemtype="http://schema.org/BlogPosting">
...
</article>
<article itemprop="blogPost" itemscope itemtype="http://schema.org/BlogPosting">
...
</article>
</div>
I have tried to implement it in a WordPress theme, perhaps my code will help you: https://github.com/pfefferle/SemPress/
will it be useful or possible to use microdata (itemdata) in my web pages built with HTML 4 code like this
<div itemscope>
<h1>Avatar</h1>
<span>Director: James Cameron (born August 16, 1954) </span>
<span>Science fiction</span>
Trailer
</div>
It would depend on whether the Microdata consumer wanted to check for HTML5-ness via the doctype or otherwise, and then disallow the microdata if the page wasn't HTML5. But it's hard to think of a reason why such a consumer would wish to go to such trouble. How would it benefit from doing so?
Having said that, using itemscope without any itemprops probably isn't going to achieve very much.
I have a quick question about RDFa and Microdata.
My current understanding is that RDFa is RDF implemented into HTML but is complicated for new developers like myself, Microdata seems really easy and quick to implement.
What are the other advantages and disadvantages around these two semantic formats ?
Differences between Microdata and RDFa
While there are many (technical, smaller) differences, here’s a selection of those I consider important (used my answer on Webmasters as a base).
Specifications
As W3C’s HTML WG found no volunteer to edit the Microdata specification, it is now merely a W3C Group Note (see history), which means that there are no plans for any further work on it.
So the Microdata section in WHATWG’s "HTML Living Standard" is the only place where Microdata may evolve. Depending on what gets changed, it may happen that their Microdata becomes incompatible to W3C’s HTML5.
Update: In 2017, work started again, with the aim to publish Microdata as W3C Recommendation.
RDFa is published as W3C Recommendation.
Applicability
Microdata can only be used in (X)HTML5 (resp. HTML as defined by the WHATWG).
RDFa can be used in various host languages, i.e. several (X)HTML variants and XML (thus also in SVG, MathML, Atom etc.).
And new host languages can be supported, as RDFa Core "is a specification for attributes to express structured data in any markup language".
Use of multiple vocabularies
In Microdata, it’s harder, and sometimes impossible, to use several vocabularies for the same content.
Thanks to its use of prefixes, RDFa allows to mix vocabularies.
Use of reverse properties
Microdata doesn’t provide a way to use reverse properties. You need this for vocabularies that don’t define inverse properties (e.g., they only define parent instead of parent & child). The popular Schema.org is such a vocabulary (with only a few older exceptions).
While the W3C Note Microdata to RDF defines the experimental itemprop-reverse, this attribute is not part of W3C’s nor WHATWG’s Microdata.
RDFa supports the use of reverse properties (with the rev attribute).
Semantic Web
By using Microdata, you are not directly playing part in the Semantic Web (and AFAIK Microdata doesn’t intend to), mostly because it’s not defined as RDF serialization (although there are ways to extract RDF from Microdata).
RDFa is an RDF serialization, and RDF is the foundation of W3C’s Semantic Web.
The specifications RDFa Core and HTML+RDFa may be more complex than HTML Microdata, but it’s not a "fair" comparison because they offer more features.
Similar to Microdata would be RDFa Lite (which "does work for most day-to-day needs"), and this spec, at least in my opinion, is way less complex than Microdata.
What to do?
If you want to support specific consumers (for example, a search engine and a browser add-on), you should check their documentation about supported syntaxes.
If you want to learn only one syntax and have no specific consumers in mind, (attention, subjective opinion!) go with RDFa. Why?
RDFa matured over the years and is a W3C Rec, while Microdata is a relatively new invention and not standardized by the W3C.
RDFa can be used in many languages, not only HTML5.
RDFa allows mixed use of vocabularies for the same content, and it natively supports the use of reverse properties.
Can’t decide? Use both.
Note that you can also use several syntaxes for the same content, so you could have Microdata and RDFa (and Microformats, and JSON-LD, and …) for maximum compatibility.
Here’s a simple Microdata snippet:
<p itemscope itemtype="http://schema.org/Person">
<span itemprop="name">John Doe</span> is his name.
</p>
Here’s the same snippet using RDFa (Lite):
<p typeof="schema:Person">
<span property="schema:name">John Doe</span> is his name.
</p>
And here both syntaxes are used together:
<p itemscope itemtype="http://schema.org/Person" typeof="schema:Person">
<span itemprop="name" property="schema:name">John Doe</span> is his name.
</p>
But it’s typically not necessary/recommended to go down this route.
The main advantage you get from any semantic format is the ability for consumers to reuse your data.
For example, search engines like Google are consumers that reuse your data to display Rich Snippets, such as this one:
In order to decide which format is best, you need to know which consumers you want to target. For example, Google says in their FAQ that they will only process microdata (though the testing tool does now work with RDFa, so it is possible that they accept RDFa).
Unless you know that your target consumer only accepts RDFa, you are probably best going with microdata. While many RDFa-consuming services (such as the semantic search engine Sindice) also accept microdata, microdata-consuming services are less likely to accept RDFa.
I'm not certain if unor's suggestion to use both Microdata and RDFa is a good idea. If you use Google's Structured Data Testing Tool (or other similar tools) on his example it shows duplicate data which seems to imply that the Google bot would pick up two people named John Doe on the webpage instead of one which was the original intention.
I'm assuming therefore that using one syntax for a given item is a better idea (you should still be able to mix syntaxes as long as they describe separate entities).
Though I would be happy to be proven wrong on this.
I would say it largely depends on the use case: For Scientific use cases, RDF is common and used in different aspects.
For enriching Websites, JSON-LD is now recommended, for example by Google.
A JavaScript notation embedded in a tag in the page head or
body. The markup is not interleaved with the user-visible text, which
makes nested data items easier to express, such as the Country of a
PostalAddress of a MusicVenue of an Event. Also, Google can read
JSON-LD data when it is dynamically injected into the page's contents,
such as by JavaScript code or embedded widgets in your content
management system.