[whatwg] Ghosts from the past and the semantic Web

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080828/325db914/attachment.htm>

Received on Wednesday, 27 August 2008 22:03:30 UTC