Ben Adida wrote:
Shannon wrote:
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.

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.

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>.

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:

<div class="whatever foo"></div>

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:

table table table div div div div p {}

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.
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.

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.

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.

<link rel="vocabulary" href="http://some.official.vocabulary/1.1/metadata.cm";>

--- or ---

<metadata>
@import http://some.official.vocabulary/1.1/metadata.htmd

-- or --

body {
   vocabulary: url(http://some.official.vocabulary/1.1/metadata.htmd);
}
</metadata>

-- or --

<div meta="vocabulary: url(http://some.official.vocabulary/1.1/metadata.htmd); title: Computer Engineer"></div>

These CSS behaviours each have benefits and drawbacks but all are widely used and understood by authors.

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...

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).

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.

If RDF or RDFa are considered too heavy to be a default language (and
they suffer from being impossible to embed inline

You should take a look at the RDFa Primer:

http://www.w3.org/TR/xhtml-rdfa-primer/

The examples show that RDFa is *built* for embedding.

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.

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.

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.

In conclusion, with this proposal you can:

* 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. * You can assign metadata properties by tag type, attributes and adjacency. The primary benefit is where custom classes and attributes aren't an option. * You can specifically target elements by class and id. The primary benefit is more clarity or specificity. * 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. * You can avoid namespace conflicts (including with local CSS) by optionally using multiple classes or nesting elements. * The structure and metadata can be separated. The benefit is both the metadata and the HTML are cleaner and easier to maintain. * Vocabularies can be joined (cascaded) or scoped using multiple classes or nesting.
* Metadata can be commented.


<metadata>
/* Example 1: Apply a standard RDF creator property to all divs and a custom artist property to all music classes */
div {
   vocabulary: url(|http://www.w3.org/1999/02/22-rdf-syntax-ns#);
 creator: John Smith;
}
.music {
|    vocabulary: url(|http://www.musiclabels.com/vocabs/blues.rdf);
 artist: Jane Simmons;
||}
</metadata>

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.
|
Shannon

Reply via email to