<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Long-Term Visibility</title>
	<atom:link href="http://meyerweb.com/eric/thoughts/2005/06/10/long-term-visibility/feed/" rel="self" type="application/rss+xml" />
	<link>http://meyerweb.com/eric/thoughts/2005/06/10/long-term-visibility/</link>
	<description>Things that Eric A. Meyer, CSS expert, writes about on his personal Web site; it&#039;s largely Web standards and Web technology, but also various bits of culture, politics, personal observations, and other miscellaneous stuff</description>
	<lastBuildDate>Tue, 18 Jun 2013 15:30:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Dan Zambonini</title>
		<link>http://meyerweb.com/eric/thoughts/2005/06/10/long-term-visibility/#comment-5726</link>
		<dc:creator>Dan Zambonini</dc:creator>
		<pubDate>Mon, 13 Jun 2005 08:38:39 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/eric/thoughts/2005/06/10/615/#comment-5726</guid>
		<description><![CDATA[I completely appreciate microformats, especially as they are quick to deploy, and seem to be more popular than RDF (or, more visible...) even though they are relatively young.

However, I don&#039;t think that the difference between RDF and microformats can be summed up with &quot;microformats are more visible&quot; - they are different technologies (and, I think, compatible).

RDF has a number of benefits... the simple model (&lt;strong&gt;something&lt;/strong&gt; has a &lt;strong&gt;property&lt;/strong&gt; of a &lt;strong&gt;value&lt;/strong&gt;) - which allows &lt;em&gt;all&lt;/em&gt; rdf information to be broken down into the same kinds of statements (unlike microformats).  Then there is the adoption of URIs for parts/all of RDF statements, that allow two people talking about &#039;London&#039; to use http://www.places.org/UK/London (for example), to ensure that the a specific instance of London is unqiuely identified.  And more RDF information can be made available at the end of URIs, really allowing a &#039;semantic web&#039; to be built.

Having said that, it is extremely disappointing that RDF is so complex, is not communicated effectively, and has so many arguments within the internal community that people are put off adopting it.

Microformats could be a big step towards helping people visualise the benefits of publishing semantic information - but I hope people don&#039;t think they are a full alternative to RDF, which is a different kettle of fish...
]]></description>
		<content:encoded><![CDATA[<p>I completely appreciate microformats, especially as they are quick to deploy, and seem to be more popular than RDF (or, more visible&#8230;) even though they are relatively young.</p>
<p>However, I don&#8217;t think that the difference between RDF and microformats can be summed up with &#8220;microformats are more visible&#8221; &#8211; they are different technologies (and, I think, compatible).</p>
<p>RDF has a number of benefits&#8230; the simple model (<strong>something</strong> has a <strong>property</strong> of a <strong>value</strong>) &#8211; which allows <em>all</em> rdf information to be broken down into the same kinds of statements (unlike microformats).  Then there is the adoption of URIs for parts/all of RDF statements, that allow two people talking about &#8216;London&#8217; to use <a href="http://www.places.org/UK/London" rel="nofollow">http://www.places.org/UK/London</a> (for example), to ensure that the a specific instance of London is unqiuely identified.  And more RDF information can be made available at the end of URIs, really allowing a &#8216;semantic web&#8217; to be built.</p>
<p>Having said that, it is extremely disappointing that RDF is so complex, is not communicated effectively, and has so many arguments within the internal community that people are put off adopting it.</p>
<p>Microformats could be a big step towards helping people visualise the benefits of publishing semantic information &#8211; but I hope people don&#8217;t think they are a full alternative to RDF, which is a different kettle of fish&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tantek</title>
		<link>http://meyerweb.com/eric/thoughts/2005/06/10/long-term-visibility/#comment-5718</link>
		<dc:creator>Tantek</dc:creator>
		<pubDate>Sat, 11 Jun 2005 00:16:38 +0000</pubDate>
		<guid isPermaLink="false">http://meyerweb.com/eric/thoughts/2005/06/10/615/#comment-5718</guid>
		<description><![CDATA[Great summary, and food (including some good questions) for thought.  

One minor clarification.  You wrote:

&lt;blockquote&gt;...title values are there in the markup as opposed to off in some other file, but from a user point of view, they&quot;re as invisible as meta keywords or RDF&lt;/blockquote&gt;

Not quite.  Meta keywords and RDF are totally invisible without &quot;view source&quot;, and even then, the latter tends to be in messy SGML comments or separate files etc.

OTOH, title values are actually somewhat visible, in that by simply hovering over the element with the title, you see a popup with the value.

One might ask, why does that matter?  After all, the intent, as with the use of abbr for presenting human dates vs. ISO8601 dates, is to hide &quot;unfriendly&quot; information from the user.

But even ISO8601 datetimes are *possible* for a human to verify.  While simply viewing the page (i.e. without doing a view source), one can simply hover over a:

&lt;code&gt;&lt;abbr title=&quot;20050610&quot;&gt;June 10th&lt;/abbr&gt;&lt;/code&gt;

e.g.

&lt;abbr title=&quot;20050610&quot;&gt;June 10th&lt;/abbr&gt;

And actually verify that yes, the ISO8601 date is the same as the date in the human visible portion.  Thus even in the case of using abbr and title to move the machine readable date aside, it&#039;s still kept where a human can &lt;em&gt;easily&lt;/em&gt; view it / verify it, should they want to, with a simple gesture, without having to navigate somewhere else.]]></description>
		<content:encoded><![CDATA[<p>Great summary, and food (including some good questions) for thought.  </p>
<p>One minor clarification.  You wrote:</p>
<blockquote><p>&#8230;title values are there in the markup as opposed to off in some other file, but from a user point of view, they&#8221;re as invisible as meta keywords or RDF</p></blockquote>
<p>Not quite.  Meta keywords and RDF are totally invisible without &#8220;view source&#8221;, and even then, the latter tends to be in messy SGML comments or separate files etc.</p>
<p>OTOH, title values are actually somewhat visible, in that by simply hovering over the element with the title, you see a popup with the value.</p>
<p>One might ask, why does that matter?  After all, the intent, as with the use of abbr for presenting human dates vs. ISO8601 dates, is to hide &#8220;unfriendly&#8221; information from the user.</p>
<p>But even ISO8601 datetimes are *possible* for a human to verify.  While simply viewing the page (i.e. without doing a view source), one can simply hover over a:</p>
<p><code>&lt;abbr title="20050610"&gt;June 10th&lt;/abbr&gt;</code></p>
<p>e.g.</p>
<p><abbr title="20050610">June 10th</abbr></p>
<p>And actually verify that yes, the ISO8601 date is the same as the date in the human visible portion.  Thus even in the case of using abbr and title to move the machine readable date aside, it&#8217;s still kept where a human can <em>easily</em> view it / verify it, should they want to, with a simple gesture, without having to navigate somewhere else.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- WP Super Cache is installed but broken. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! -->