<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ben Adida wrote:
<blockquote cite="mid:48B60D28.50909@adida.net" type="cite">
<pre wrap="">Shannon wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I think you were on to something with the CSS-like approach. Ian has
stated earlier that class should be considered a generic categorisation
element rather than only a CSS hook.
</pre>
</blockquote>
<pre wrap=""><!---->
Three things:
1) specifying the semantics only in a separate file rules out a very
important use case: the ability to simply paste a chunk of HTML into
your site and have it carry with it all metadata. Think MySpace, Google
widgets, Creative Commons,.... This is crucial to the design of
HTML-based metadata.
</pre>
</blockquote>
<br>
Who said anything about it only being in a separate file? My original
example was local to a snippet in the same way as <script> and
<style>.<br>
<br>
Due to the cascading nature of CSS rules this would extend the MySpace
default vocabulary. If the metadata rules are are namespaced ( as in
.myspace.foo {} and .whatever.foo {} ) then conflicts are resolved by:<br>
<br>
<div class="whatever foo"></div><br>
<br>
Since you brought up these systems I should point out that I have some
experience with these platforms and myspace in particular can be quite
ruthless about stripping unsupported attributes and deciding which
parts of the page you can change. Hooking your metadata into MySpaces
structure through selectors is probably going to be the only way to
associate metadata with parts of the page. I've seen many rules to
target MySpace panels that look like this:<br>
<br>
table table table div div div div p {}<br>
<br>
If it were possible to put a class or property on that element this
would not be necessary. If you can't put a class on there then you're
going to be out of luck with RDFa attributes.<br>
<blockquote cite="mid:48B60D28.50909@adida.net" type="cite">
<pre wrap="">
2) the CSS approach you're proposing is local to the web
site/application: very hard to reuse things like "item price" across
sites in a way that will be consistent. That's what URIs are for.
</pre>
</blockquote>
<br>
Just like CSS it can be local OR global depending on where you @import
or link your metadata and vocabularies from and how you nest and
combine classes. The impact of multiple vocabularies is a social issue
that no format can solve. In other words just because RDFa encourages
dc: and rdf: does not mean they will be used consistently - and if they
were then these groups become a bottleneck in growing the metadata
space. There is no solution for this that makes everyone happy.<br>
<br>
However to be on par with RDFa this proposal simply needs a CSS-like
@import statement or vocabulary property and possibly an inline
attribute as Silvia suggested.<br>
<br>
<link rel="vocabulary"
href=<a class="moz-txt-link-rfc2396E" href="http://some.official.vocabulary/1.1/metadata.cm">"http://some.official.vocabulary/1.1/metadata.cm"</a>><br>
<br>
--- or ---<br>
<br>
<metadata><br>
@import <a class="moz-txt-link-freetext" href="http://some.official.vocabulary/1.1/metadata.htmd">http://some.official.vocabulary/1.1/metadata.htmd</a><br>
<br>
-- or --<br>
<br>
body {<br>
vocabulary: url(<a class="moz-txt-link-freetext" href="http://some.official.vocabulary/1.1/metadata.htmd">http://some.official.vocabulary/1.1/metadata.htmd</a>);<br>
}<br>
</metadata><br>
<br>
-- or --<br>
<br>
<div meta="vocabulary:
url(<a class="moz-txt-link-freetext" href="http://some.official.vocabulary/1.1/metadata.htmd">http://some.official.vocabulary/1.1/metadata.htmd</a>); title: Computer
Engineer"></div><br>
<br>
These CSS behaviours each have benefits and drawbacks but all are
widely used and understood by authors.<br>
<br>
<blockquote cite="mid:48B60D28.50909@adida.net" type="cite">
<pre wrap="">
3) reinventing metadata from scratch, and without URIs? Is that really
necessary? We're trying to reuse years' worth of important work from the
RDF community. There are so many important issues to consider regarding
the reuse of vocabularies, the ability to discover basic information
about vocabularies, etc...
</pre>
</blockquote>
<br>
Metadata comes in a large number of syntaxes of which RDF is only one.
Since nearly all are text-based most can be easily transcribed from one
to the other. I don't think the format is important one way or the
other except when you want to embed the vocabulary in a HTML page. RDF
can't do that because it's vocabularies are XML. RDFa simply specifies
a relationship between parts of two documents and is therefore not
entirely different to @class, @rel or anchor fragments and in itself
does not appear to be "years of work" (except in advocacy maybe).<br>
<br>
I don't see why RDF can't be parsed as an import. I was simply
demonstrating that it is not necessary or desirable for all metadata
properties of an object to be defined directly ON the element. They can
be described elsewhere and associated through the use of CSS-like rules.<br>
<br>
<blockquote cite="mid:48B60D28.50909@adida.net" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">If RDF or RDFa are considered too heavy to be a default language (and
they suffer from being impossible to embed inline
</pre>
</blockquote>
<pre wrap=""><!---->
You should take a look at the RDFa Primer:
<a class="moz-txt-link-freetext" href="http://www.w3.org/TR/xhtml-rdfa-primer/">http://www.w3.org/TR/xhtml-rdfa-primer/</a>
The examples show that RDFa is *built* for embedding.
</pre>
</blockquote>
<br>
RDFa is just a bunch of custom attributes. I meant you can't embed the
RDF vocabulary. You may say site-specific vocabularies are a bad idea
but I have to disagree there. It is extremely common for small groups
to develop their own "lingo". Just pick any online game forum and try
and make sense of TK, Gold Farming, combomb, wtf, etc without playing
it. It may not be useful for browsers to understand this 'vocabulary'
but game-specific tools might. The vocabulary might be small enough to
not warrant a separate file and there may be no central server
providing a common vocabulary anyway.<br>
<br>
My point is that the CSS-like syntax allows all or part of a vocab
and/or properties list to be optionally embedded in the page and this
is not always a bad thing.<br>
<br>
But the real point of all this wasn't just to recommend a new syntax
but rather to recommend the reuse of class and selectors rather than
the creation of new and clearly controversial attributes. Since CSS is
familiar to web developers AND already implements the extension and
selection mechanisms to target specific elements and groups it is
superior to RDFa in many ways.<br>
<br>
In conclusion, with this proposal you can:<br>
<br>
* Import OR embed official OR unofficial metadata and vocabularies with
OR without modifying the target element. This is consistent with
authors (including CC's) actual needs.<br>
* You can assign metadata properties by tag type, attributes and
adjacency. The primary benefit is where custom classes and attributes
aren't an option.<br>
* You can specifically target elements by class and id. The primary
benefit is more clarity or specificity.<br>
* You can store the metadata locally or remotely and in any format (ie,
RDF, ID3) that can be parsed by the agent to key/value pairs.<br>
* You can avoid namespace conflicts (including with local CSS) by
optionally using multiple classes or nesting elements.<br>
* The structure and metadata can be separated. The benefit is both the
metadata and the HTML are cleaner and easier to maintain.<br>
* Vocabularies can be joined (cascaded) or scoped using multiple
classes or nesting.<br>
* Metadata can be commented.<br>
<br>
<br>
<metadata><br>
/* Example 1: Apply a standard RDF creator property to all divs and a
custom artist property to all music classes */<br>
div {<br>
vocabulary: url(<code><a class="moz-txt-link-freetext" href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a>);<br>
creator: John Smith;<br>
}<br>
.music {<br>
</code> vocabulary: url(<code><a class="moz-txt-link-freetext" href="http://www.musiclabels.com/vocabs/blues.rdf">http://www.musiclabels.com/vocabs/blues.rdf</a>);<br>
artist: Jane Simmons;<br>
</code><code>}<br>
</metadata><br>
<br>
Anyway I'm just saying the OP was right. RDFa solves nothing that CSS
syntax and classes can't, except that CSS syntax is familiar, simpler,
more flexible AND more powerful. A win-win-win-win for authors.<br>
</code><br>
Shannon<br>
</body>
</html>