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

Re: Summary of @href/@resource completing triples issue (v2.0)

From: Ivan Herman <ivan@w3.org>
Date: Thu, 10 Jan 2008 12:32:17 +0100
Message-ID: <47860241.80902@w3.org>
To: Mark Birbeck <mark.birbeck@formsPlayer.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, RDFa <public-rdf-in-xhtml-tf@w3.org>

I think you put way too much into my words and/or I was 
misunderstandable... Sorry about that.

I do _not_ want to come back to the usage of @href in general *at all*. 
What I meant was:

- we *may* consider it a special case when @href appears in an element 
without any other RDFa elements (yes, this would include @rel/@rev and I 
agree this would weaken this case)
- *if* we do that then, and *if* we give a high priority to the 
@resource/@href symmetry then we would impose the same restriction on 
@resource but we could decide to break this symmetry on that point.


<div href="#a><span rel="a:b" resource="#b"/></div>


<div resource="#a><span rel="a:b" resource="#b"/></div>

would *not* behave the same way, ie, the first would not generate any 
triple whereas the second would.

That is all. Let us not make a big deal out of this one.


Mark Birbeck wrote:
> Hi Ivan,
> You wrote:
>> No big deal, but nevertheless... I guess the issue here is that the
>> usage of @href is overloaded in RDFa for clickable and RDF reasons and
>> that may lead to problems. And that is why my initial instinct was to
>> say that @href "does" something in RDFa-land only when it appears with
>> some other RDFa attribute (ie, the user knows what he/she is doing...)
>> I am not saying it is a big issue, and we may live with that. I just
>> wanted to air my discomfort, and thereby adding to the overall confusion
>> before we get too tired:-)
>> Of course, the argument above does not apply if I use @resource. Ben was
>> asking somewhere whether we should consider the symmetry of @href and
>> @resource as immutable, and that is a valid question of course...
>> Although I believe we should try to keep these two together...
> But this is the key question that is under discussion, so I think you
> do need to say whether you can live with it or not...and whether it is
> a "big issue" or not.
> As I said in another post, if this _is_ a "big issue" for you, then
> the only truly consistent way out of this is to remove @href from the
> RDFa attribute list altogether.
> I know that you are saying that we _could_ just limit @href's
> operation to only apply when another RDFa attribute is present, but I
> assume you are including @rel and @rev in that list? And as I
> explained yesterday, since they are HTML attributes independent of
> RDFa, it just leaves exactly the same issue that you are uncomfortable
> with; you still can't mark things up in a 'standard' HTML way, in a
> way that will not generate a triple.
> But as I also said, that approach takes us back 4 years! The
> incorporation of @href into RDFa is what led to Ben's 'bridging the
> clickable and semantic webs' formulation that we all love to quote.
> So either we're going to bridge the two webs, or we're not.
> These are hard decisions, I know, but we need to have some balls here
> (if you'll excuse the expression) and make the leap. The whole reason
> that RDF and HTML were never integrated prior to the RDFa proposals
> was that everyone was always avoiding the bold step of actually
> changing HTML. But someone has to take that bold step at some point,
> and I thought it was going to be us. It is simply not possible to
> fulfil a requirement that @href generates triples, at the same time
> that it does not generate triples...we're bounded by logic here. :)
> You need to say how big an issue this is for you, and if it's not that
> big a deal we should get on and bridge those webs.
> Regards,
> Mark


Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Thursday, 10 January 2008 11:32:11 UTC

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