Re: Statements about links in XHTML 2 [was RE: customer feedback, please]

Mark,

I believe we can find a solution which combines
	1) GRDDL's simple, unified expression of RDF information inside 
visible XHTML, and
	2) RDF/XHTML's consideration of XHTML as a full-fledged mechanism for 
expressing RDF statements.

Currently, each solution makes RDF a kind of second-class citizen 
within XHTML, (1) by requiring an XSL transform, (2) by ignoring the 
existing structure of XHTML as a starting base for RDF statements.

You're definitely correct to point out that I am interested in links 
above all. What I'm confused about in your message is:

	A) the comparison to XForms: XForms seems to already contain 
well-typed links. Specifically in the example you give, 
<xforms:instance> defines the type of the @src attribute quite well. We 
know what the @src link means, because it's inside an xforms:instance 
element which effectively types it. Thus, <xforms:instance> seems 
qualitatively different from <a>.

	B) the requirement that the "rel" attribute must have proper meaning 
inside all sorts of other elements: Maybe I'm misusing "rel", in which 
case we can certainly use another attribute. If we try to provide an 
RDF type to the <a> link, do we have to make sure that attribute has 
exactly the same meaning (and exists) in all other elements. Is that 
the way it works for all attributes? Must they have meaning inside 
every element?

In form, GRDDL is a better fit because it's simply trying to add typing 
information to already-existing but weak links. In principle, though, 
GRDDL assumes that XHTML is a secondary format for expressing RDF and 
the first important step is to extract the RDF/XML. That's too bad and, 
I think, not necessary. There is something very attractive about 
RDF/XHTML in that it makes XHTML just as valid a format for expressing 
RDF statements as XML or N3. The indirection solution you're proposing, 
however, would significantly take away from this fantastic aspect of 
RDF/XHTML: it would make expressing RDF statements in XHTML a bit of a 
retrofit, and would effectively send the message "use RDF in XHTML only 
if you really have to, because RDF/XML is better." I don't think it has 
to be that way.

So, can we get GRDDL's simple unified expression of RDF (visible links 
are typed to become RDF links) and RDF/XHTML treatment of XHTML as a 
first-class language for expressing RDF statements?

I defer to you and other XHTML experts (i'm certainly not one!) to help 
make this fit the XHTML paradigms nicely, of course, I just thought 
that my overall end-goal wasn't expressed correctly in my last email.

Taking into account Nick's comments about GRDDL:

- the profile attribute in GRDDL is definitely something that bothers 
me, especially since it is really only there to give context 
(namespace?) to rel types in the document. Could this be another reason 
to think about fully qualified rel types, or XML namespace ways of 
doing rel types?

- which transformations apply? If you consider XHTML to be a 
first-class language for expressing RDF statements, then the 
transformation is only useful if you want to consume your RDF in pure 
XML, and that transformation can be defined by a resource associated 
with the RDF type of the rel. With fully qualified rel types (either 
directly or through namespace), the transformation is easily identified 
in the XHTML as living at a given URI, which a reasoning program can 
follow, where further RDF information (expressed either in XHTML or 
XML, your choice) can link to resources to help you transform the 
RDF/XHTML into RDF/XML. No need for a catalog of transforms, just 
follow the links.

So I guess what I'm saying is that I like GRDDL as a basis, and I would 
like it even more if it were infused with certain principles of 
RDF/XHTML, specifically making XHTML a first-class language for 
expressing RDF.

-Ben


On Mar 25, 2004, at 7:23 AM, Mark Birbeck wrote:

>
> Hello Ben,
>
> The points you raise are extremely interesting. My general feeling
> though is that we have to be careful to ensure we provide generic
> solutions.
>
> First let me see if I understand the problem. You are saying that there
> is some document that has a license defined externally, and you would
> like to make a connection between the document and the license. In
> RDF/XHTML this would be expressed as:
>
>   <html xmlns:cc="http://web.resource.org/cc/rels/">
>     <head>
>       <link
>        rel="cc:license"
>        href="http://creativecommons.org/licenses/by-nc/1.0/"
>       />
>     </head>
>     <body />
>   </html>
>
> Also, somewhere within the document is a link that users can navigate 
> in
> order to read the license:
>
>> <a rel="http://web.resource.org/cc/rels/license"
>> href="http://creativecommons.org/licenses/by-nc/1.0/">
>> Creative Commons License
>> </a>
>
> You seem to be saying that firstly this feels like unnecessary
> duplication. And secondly, it would be more correct to say that "we 
> have
> a link, and a property of this link is that it is the license for this
> document".
>
> Whilst I would sympathise - and in fact would like to solve this - I'm
> very keen to do so in a generic way. It is only because you know the
> 'role' that @href is playing on <a> that you can decide you would like
> it to express more than just being a link for users to click on. That 
> is
> difficult to generalise, though. Say the attribute was the CSS class -
> what would this mean?:
>
>   <span rel="xx:yy" class="selected"> ... </span>
>
> Would that still be a statement about an attribute, or are we not
> interested in non-URI attributes? If we can make statements about the
> contents of any attribute, what would it mean if there were two
> attributes on <a>? How would you decide which one you are making
> statements about?
>
> Of course, the reality is you are probably only interested in links. 
> But
> whatever solution we come up with, we wouldn't want to confine it to
> just @href attributes, since there are a lot of other useful situations
> where we might employ what you need. For example, XForms uses @src in
> some situations:
>
>   <xforms:model>
>     <xforms:instance
>      rel="xx:yy"
>      src="http://example.com/intitialData"
>     />
>   </xforms:model>
>
>
> What I'm wondering therefore, is whether we could extend the RDF/XHTML
> syntax we already have; metadata can already be nested inside the items
> to which it refers:
>
>   <html xmlns:dc="http://purl.org/dc/elements/1.1/">
>     <head />
>     <body>
>       <blockquote id="q1">
>         <link rel="dc:source" resource="urn:isbn:0140449132" />
>         <p>
>           'Rodion Romanovitch! My dear friend! If you go on in this way
>           you will go mad, I am positive! Drink, pray, if only a few
> drops!'
>         </p>
>       </blockquote>
>     </body>
>   </html>
>
> This seems to fit 'conceptually' with what you are after, although in
> it's current form it doesn't work for you, for two reasons:
>
> 1. You want to make a statement about "a/@href", and not "a".
> 2. You want the subject of the statement to be the 'current'
>    document.
>
> The second issue looks like it needs solving anyway, and I've already
> been looking into it. I'm thinking that all we need to do is retain the
> use of @rev in <link>, in much the same way that it is used at the
> moment. This 'reversal' syntax would be useful in many situations:
>
>   <table id="menu">
>     <link rev="widget:menu" href="#" />
>     <thead />
>     <tbody />
>   </table>
>
> Unfortunately, it's still not quite right for you, since this:
>
>   <a id="lic" href="http://creativecommons.org/licenses/by-nc/1.0/">
>     <link rev="cc:license" href="#" />
>     Creative Commons License
>   </a>
>
> would give us this:
>
> <> <http://web.resource.org/cc/rels/license> <#lic> .
>
> which is close ... but not close enough!
>
> To finish the jigsaw then, there are two ways we could go in addressing
> problem 1. One is to say that:
>
>   any URI attribute on an element can become the
>   subject (or object, if using @rev) of nested
>   statements.
>
> At the moment I specifically allow the following structure:
>
>   <link rel="dc:copyright" href="http://example.com/company/BBC/6">
>     <meta property="dc:location">London</meta>
>   </link>
>
> but we could make the whole thing more general, and allow this to work
> with any URI on the parent element. If we did that, we would probably
> have to say that @id takes precedence though, since we still need to be
> able to do this:
>
>       <blockquote id="q1">
>         <link rel="dc:source" resource="urn:isbn:0140449132" />
>         <p>
>           'Rodion Romanovitch! My dear friend! If you go on in this way
>           you will go mad, I am positive! Drink, pray, if only a few
> drops!'
>         </p>
>       </blockquote>
>
> but since in XHTML 2 @href can appear anywhere, we would not want this
> reference to suddenly change meaning if the author makes the quote into
> a link.
>
> The second way is to leave things as they are in RDF/XHTML (with the
> addition of @rev) and work out some way of getting the information
> associated with <a> out as triples too. Your syntax would then be 
> either
> this:
>
>   <a id="lic" href="http://creativecommons.org/licenses/by-nc/1.0/">
>     <link rev="cc:license" href="#" />
>     Creative Commons License
>   </a>
>
> or this:
>
>  <html xmlns:cc="http://web.resource.org/cc/rels/">
>     <head>
>       <link
>        rel="cc:license"
>        href="#lic"
>       />
>     </head>
>     <a id="lic" href="http://creativecommons.org/licenses/by-nc/1.0/">
>       Creative Commons License
>     </a>
>   </html>
>
> If we could then work out a way to 'expand' all links in the document 
> to
> triples (and I have two or three ideas), then your triples would look
> like this:
>
> <> <http://web.resource.org/cc/rels/license> <#lic> .
> <#lic> <http://www.w3.org/xlink/simple>
> <http://creativecommons.org/licenses/by-nc/1.0/> .
>
> (Just using XLink as a place-holder to illustrate the point.)
>
> It would then be a simple case of adding some equivalence rules.
>
> Before I go any further, from the metadata viewpoint is the latter
> acceptable? Is the extra level of indirection a problem? Any thoughts 
> or
> preferences?
>
> Regards,
>
> Mark
>
>
> Mark Birbeck
> CEO and CTO
> x-port.net Ltd.
>
> Download our XForms processor from
> http://www.formsPlayer.com/
>
>
>
>> -----Original Message-----
>> From: public-rdf-in-xhtml-tf-request@w3.org
>> [mailto:public-rdf-in-xhtml-tf-request@w3.org] On Behalf Of Ben Adida
>> Sent: 19 March 2004 19:00
>> To: Dan Connolly
>> Cc: RDF in XHTML task force; public-swbp-wg@w3.org
>> Subject: Re: customer feedback, please
>>
>>
>>
>>
>> Greetings to both the TF and the WG,
>>
>>
>> At Creative Commons, we need a solution for including RDF
>> statements in HTML chunks (XHTML 1.0/2.0, non-compliant HTML,
>> etc...). The two solutions presented have some attractive
>> qualities, but they don't work for CC yet.
>>
>> For CC - and I believe for XHTML users in general - an RDF
>> expression solution should have the following properties:
>> 	(1) a chunk of HTML, independent of the HEAD or BODY
>> tags, can include RDF statements.
>> 	(2) whenever possible, RDF statements should be
>> intimately tied to what a user sees in the visible portions
>> of the XHTML.
>>
>> It seems that (1) is given to us by the XHTML/RDF proposal,
>> and (2) by the GRDDL proposal, but really we need both for
>> this stuff to take off.
>>
>> So, here's something that would work:
>>
>> <!-- Begin Creative Commons License -->
>> This document is licensed under a
>> <a rel="http://web.resource.org/cc/rels/license"
>> href="http://creativecommons.org/licenses/by-nc/1.0/">
>> Creative Commons License
>> </a>
>> <!-- End Creative Commons License -->
>>
>> which would be translated to N3 notation as:
>>
>> <> <http://web.resource.org/cc/rels/license>
>> <http://creativecommons.org/licenses/by-nc/1.0/">
>>
>> Using XHTML 2, one could wrap that in a SPAN with a CC
>> namespace and have a Qname REL attribute like cc:license. Dom
>> mentioned that this is not recommended by current standards,
>> but I question why that is: isn't the end goal of this whole
>> effort to qualify links in the spirit of the web and RDF?
>>
>> The really interesting aspect of this approach is that the
>> relationship is tied to what the user can observe by clicking
>> through on the link! It's just a qualification of the link,
>> which fits nicely into the RDF paradigm.
>>
>> The document at the rel type URI can include all sorts of
>> additional information in RDF format, including:
>> 	- a link to an XSLT script that would yield RDF/XHTML
>> (a-la GRDDL)
>> 	- a human description of this type of link
>> 	- links to any other tools that are relevant
>> 	- etc...
>>
>> Why can't we do this (or something similar)?
>>
>> The GRDDL weakness is that it currently requires a HEAD
>> profile, which is bad because:
>> 	- HTML chunks can't contain CC licenses
>> 	- there's only one possible profile for the whole page
>>
>> The XHTML/RDF weakness is that it doesn't tie the LINK to the
>> actual observable link that users click through, which leads
>> to large headaches in terms of XHTML maintenance over time
>> (say you choose a new license... are your metadata and
>> user-observable HTML link still consistent?)
>>
>> How can we get these to work together to yield the highly
>> desirable properties (1) and (2) from above? In other words,
>> how can we augment the current XHTML standards to enable
>> current, "weak links" to become RDF-strong links?
>>
>> -Ben
>> ben@mit.edu / ben@creativecommons.org
>>
>>
>> On Thu, 2004-03-18 at 11:56, Dan Connolly wrote:
>>> I'd like to check in with anybody who feels like a customer,
>>> especially the intersection of this task force with the
>> Semantic Web
>>> Best Practices WG.
>>
>>
>>
>

Received on Tuesday, 30 March 2004 12:51:37 UTC