[whatwg] Ghosts from the past and the semantic Web

[Ben Adida]

Silvia Pfeiffer wrote:
>> 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.
> 
> So you would just cut and paste two pieces of text:  the HTML and the
> relevant metadata from the separate file - I don't see that as a big
> deal.

Actually, it's a really big deal. Have you gone through the Creative
Commons license generation process? You really need to say "just paste
this somewhere on your page." Asking an average user to paste two
different pieces of content in two different places ("what's CSS?") is a
complete deal breaker in terms of usability.

Same goes with MySpace widgets. Paste one thing, get the widget. Who's
going to go paste two things in two different places? It's really
important to make HTML the carrier of this information.


> It is the same issue that we have with css files and people
> prefer it that way mostly.

Two things:

a) the CSS example is interesting: do you think the average user knows
how to copy HTML and CSS separately and properly have HTML reference
CSS? In my experience, no way.

b) With CSS, you *can* set the style directly in the HTML when you need to.

> I think in addition to creating a metadata tag that links to an
> external file, we could also consider to invent a "metadata" attribute
> - analogously to the "style" attribute. Then we have the best of both
> worlds: ability to include semantics inside the file and in a separate
> file.

So, if there's a lot of metadata on the page, where would the metadata
tag go? Would there be a whole bunch of them? Seems like not really
ideal design.

Rather, like CSS, using attributes seems like the right way to annotate
existing HTML. We just need 4 for complete generic RDF expression,
rather than just one.

> I am still struggling with the need for using URIs to address resource
> properties rather than resources.

How do you differentiate "Job Title" from "Book Title" in a way that
scales to the web? You need unique identification, and a way to explore
more information about the data field.

That's why URIs are useful

  http://purl.org/dc/elements/1.1/title

That's a document title, and a program can easily figure that out by
going to that URL.

> It is important to understand the needs of the RDF community.

It's not really the needs of the RDF community. It's the need of folks
like Creative Commons, and Digital Bazaar, and the UK National Archives,
and many more. RDF is a mature technology that makes sense here. So it's
about picking a well-thought-out design, rather than reinventing the
wheel, yet again, and making the same mistakes, yet again.

> However, it is also important to understand the history in which similar issues
> have been solved in other and usable ways. And to understand which
> issues really cannot compared to any past issues and need a novel
> approach to solving it.

If HTML can be "extended" with metadata using @class, the way
microformats do it, then I don't see a conceptual conflict. The question
is whether @class is sufficient. And I think we're making a reasonable
argument that it isn't for a number of crucial use cases.

-Ben