<div dir="ltr">On Thu, Aug 28, 2008 at 7:13 AM, Eduard Pascual <span dir="ltr"><<a href="mailto:herenvardo@gmail.com">herenvardo@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think some of you got my point quite better than others; and maybe I<br>
should clarify the idea. I see no issue with having some attributes to<br>
embed semantics inline within the HTML, the same way we have style to<br>
embed presentation. The issue is about *forcing* these semantics,<br>
which are not the structure of the document, into the HTML, which is<br>
intended to represent structure.<br>
Although I tried to simplify using only the CSS paralellism (also,<br>
presentation is what ruined HTML3.2, while behaviour just stood<br>
there), Toby has seen deeper than the example and got the exact point<br>
;-) (although I don't entirely agree with the analogy).<br>
<br>
Following on with the parallellism:<br>
<br>
style="...": inline styles, quite related to things like<br>
onclick="javascript:goBack();" (inline script statements); this would<br>
be equivalent to the current property="" and about="". There is no<br>
issue with them, just that I feel they are not enough. This solves<br>
some cases, but not all.<br>
<br>
class="..." when used explicitly to tie with a CSS .class selector;<br>
relates to the usages of onclick="javascript:myFunction();" (rather<br>
than doing all the work there, it hooks with a function defined<br>
somewhere else); and there is currently no equivalent for semantics.<br>
<br>
<style> and <script> are used to define document-wide styles and<br>
behaviors. Once again, we lack something to achieve this for<br>
semantics. Introducing a <metadata> element as suggested could be a<br>
solution (I'd rather prefer <semantics>, but that's mostly a matter of<br>
taste), but if somebody has any better idea I'd be glad to hear it.<br>
<br>
<link rel="stylesheet"> and <script src="..."> allow to import<br>
stylesheets and scripts that might be shared by several documents. I<br>
guess <link> could be used to import semantics as well.<br>
<br>
<br>
On the copy-pasting issue mentioned above, I have to disagree: copying<br>
CSS'd contents from a webpage normally preserves the formatting on<br>
most browsers, so I can't see why other kinds of metadata could be an<br>
issue.<br>
<br>
Before finnishing, I have come up with a use-case that might help to<br>
illustrate my point. I (hipotetically, because my site is still under<br>
construction) have several projects listed on my website. It'd be a<br>
good idea, on each project's own page, to have embeeded metadata, such<br>
as Title, Author, License, and more specific stuff such as target<br>
platform, intended audience, programming language, version number,<br>
release date, and what-not.<br>
Until that point, embeeded RDF information does the job quite well.<br>
But I also have a page listing all the projects, with some details<br>
about them. Repeating 20 or 50 times will start bloating the code<br>
quite a bit, and it would be extremelly redundant. Ideally, I would<br>
like to be able to define some kind of "pattern" (be it an XPath<br>
expression, a CSS-like selector, or any other way) to represent for<br>
example that the first entry of each project is the title, the second<br>
is the version, then the date, license, and so on. The current<br>
approach for RDF in HTML fails to handle this without extremelly<br>
annoying redundance.</blockquote><div><br>THIS. This was my unarticulable objection to RDFa. I understand that carrying the data around as close to the relevant html as possible is good, and making it possible to embed things like CC licenses with all relevant metadata in a single copypaste operation is awesome, but the redundancy of this being the *only* way to embed it in html bothered me.<br>
<br>Using the Selectors module to target things and apply the metadata would be wonderful. It's the most well-known and widely-applied element selection syntax, familiar to web authors across the world.<br><br><blockquote>
> * You can store the metadata locally or remotely and in any format (ie,<br>
> RDF, ID3) that can be parsed by the agent to key/value pairs.<br><br>Key/value pairs are not enough. We need the subject, too. Triples.<br></blockquote>
</div></div>Yes, easy. Use some equivalent to an @ rule. Frex:<br><metadata type="text/rdf"><br>@namespace( "<a href="http://www.somenamespace.com/rdf">http://www.somenamespace.com/rdf</a><a href="http://purl.org/dc/elements/1.1/title" target="_blank">" ) {</a><br>
.person {<br> scope: base;<br> }<br><br> .person .name {<br> name: content;<br> }<br><br> .person .title {<br> job-title: content;<br> }<br><br> #john-doe {<br> name: "Richard Smith";<br> job-status: "retired";<br>
}<br>}<br><br>@namespace( "<a href="http://www.somefriendlynamespace.com/rdf">http://www.somefriendlynamespace.com/rdf</a>" ) {<br> .person {<br> scope: base;<br> }<br><br> #jane-doe {<br> loves: url( #john-doe );<br>
}<br>}<br></metadata><br><br>(I introduced the scope: property for hopefully obvious reasons, but it's very likely not the optimal way to go about this.)<br><br>Like Eduard, I see the utility in specifying the metadata inline. I also see the downside in specifying the metadata completely outside of the content (it'll inevitably get out of date). However, meeting these two somewhere in the middle allows us to leverage the same sort of benefits that CSS brought over <font> tags; namely, the powerful DRY principle when we've got a lot of data with the same structure across a web site.<br>
</div>