W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > June 2004

Re: Turning XHTML links into RDF statements

From: Ben Adida <ben@mit.edu>
Date: Mon, 14 Jun 2004 14:46:35 -0400
Message-Id: <29A57CA4-BE33-11D8-A2EA-0003939247DC@mit.edu>
To: 'RDF in XHTML task force' <public-rdf-in-xhtml-tf@w3.org>


I think I am starting to understand the difference in our positions. I 
believe very strongly that @href is a fundamental construct of the web, 
one that is fundamentally different from other attributes, because it 
establishes a clickable link in all current HTML parsers and standards. 
I get the feeling that the XHTML2 effort is de-emphasizing the use of 
@href, making it no longer "special." Is that accurate?

I'm somewhat worried about this, given the existing HTML's reliance on 
@href. At the end of the day, XHTML needs to establish *some* meaning 
for its defined attributes, right?

I also want to make it very clear that I believe the requirement I've 
laid out has an audience far larger than just Creative Commons. We may 
be one of the biggest users of RDF, but we're not interested in a 
CC-specific standard. On the contrary, we want something that is going 
to last. I can think of applications to FOAF and just about any other 
RDF-logic that benefits from being embedded in a web page.

And most important, I want to point out that the inclusion of RDF in 
XHTML is a real problem that numerous people are trying to resolve in 
dozens of different ways: if we go with RDF-lite, or with a poor 
inclusion mechanism that fails to unify identical statements across 
XHTML and RDF, then we leave a wide-open hole for dozens of ad-hoc 
implementations. The need is out there, and it's much bigger than 
Creative Commons.

More details on this in response to your specific comments:

> The same reason that RDF is different to the size of a font - my point
> remains that you are using some special knowledge that you have about 
> what
> one of the attributes in XHTML 2 represents. That is to say, you 
> 'know' that
> @href establishes the ability for a navigator to move from one 
> document to
> another, and you want to use that knowledge to establish an RDF 
> relationship
> between the two end-points. But I very strongly believe that this is 
> wrong,
> from both an XHTML point-of-view, and, as it happens an RDF one.
> With respect, I think you are using RDF a little loosely here - RDF 
> does not
> "establish links", clickable or otherwise. Perhaps that is the core of 
> our
> difference, since I feel that your proposal is conflating resources and
> documents; it just so happens that they are both represented by URIs, 
> but
> that does not mean that they can be used interchangeably.

So, this might be a vocabulary difference. Maybe I should rephrase it. 
How about "RDF establishes relationships between resources." Certainly, 
@href does, too. Even assuming a browser doesn't need to interpret 
@href as a clickable link, @href definitely establishes a relationship 
of sorts between the current document and the @href-referenced URI.

> But that's the point - @resource is the *only* thing that is special. 
> With
> the new attributes you can carry RDF in any XML without knowing 
> anything
> about what the mark-up represents.

Does this mean that XHTML2 considers @href to have no special meaning 
related to linkage? That @href is not required to be interpreted as a 
clickable link? How will you handle the backwards compatibility on this 

> But also, @resource only represents a
> URI, not a 'link' as you refer to it. Maybe an example will help. If an
> author chooses to make a statement that some document has a property 
> called
> 'stylesheet' and the value of that property is the resource
> <http://blah.com/x.css> than that does not in any way imply that a 
> document
> really exists at that location, containing style rules. In other words 
> we're
> talking *real* RDF here. Now ... the fact that a browser would 
> hopefully
> implement a system whereby it tries to retrieve the stylesheet 
> referred to
> might be pretty good, but it also might be the case that there is no
> document that 'maps' to that resource, and in fact the browser should 
> use a
> look-up to retrieve some local *document* (stylesheet) identified by 
> the
> *resource*.

I see your point, and it's a good one. If I understand correctly, 
you're saying that a resource, though it may be a URI, need not require 
a web fetch. In other words, an RDF statement is not necessarily a link 
to a real resource.

I'm stating the opposite relation, which I think is correct: any 
relationship between two real resources *is* an RDF statement, even if 
not all RDF statements establish relationships between real resources. 
Thus, any @href attribute easily translates to a basic RDF statement.

> Having said all of this, I'm not at all saying that I don't have 
> sympathy
> for the problem. But I don't think we can just declare the equivalence 
> of a
> document identified by @href and the subject of an RDF triple and be 
> done.

What about declaring the equivalence when there is no @resource 
specified? Or finding a way to turn an @href into an RDF statement 
using another attribute (other than @rel)? It seems clear that @href is 
establishing relationships, so why not qualify them?

> (1) You just use <a href="..."> as is, to identify the CC license in 
> the
> document, and then in your triple store you add an inference that says 
> that
> the resource with a URI that is the same as that used in the @href 
> attribute
> of the link, has an rdf:type of CC license.

This leaves open the possibility of highly inconsistent documents 
because the URI must be referenced twice when you're only trying to 
make one statement. It makes XHTML a very poor language for expressing 
RDF and will lead to people back to using RDF/XML.

> (2) You drop the <a href="..."> and instead have a <link rel="cc:lic"
> resource="..." /> statement in the header. We then ensure that future 
> 2 web browsers make use of this type of meta information to render a
> navigable link to users so that they can read the licence. (This is a
> general requirement, since there are many other features that can be 
> used,
> like @rel="next" and @rel="previous", which have no mandated 
> behaviour, but
> a syntax is provided.)

This is CC-specific. What about people who want to have a FOAF list as 
XHTML ("Here are my friends and their web pages, and at the same time 
this has RDF semantics"). Building the semantics of each application 
into the browser doesn't seem right.

> Personally, I could live with either of these - number 1 because it 
> seems
> right to me that we draw a sharp line between a simple link and the
> statements made about some document; and number 2 because I think 
> browsers should do a lot of this sort of thing, making use of meta 
> data to
> show author and document properties, and so on.

I think this goes to the crux of what I'm having trouble understanding: 
since @href already establishes relationships, why the resistance to 
qualify these relationships? Why the push to lock these "simple" 
relationships out of this great system (RDF) for qualifying *all* 

> I hope this helps clarify at least where I am coming from in my 
> resistance
> to the proposal as it stands.

I think I'm starting to understand, but more discussion will probably 
help. I hope my arguments help explain why I think this issue is much 
larger than CC and needs a real solution.

Received on Monday, 14 June 2004 14:46:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:18 UTC