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

Manu Sporny wrote:
> Sorry folks, Ben's right, there were several bugs in the last summary...
> I'm repeating this because all three of these should turn into test
> cases and we need to make sure that they're correct representations of
> the issue:
> 
> This works for both models:
> 
> -----------------------------------------------------------------
> <div href="#me">
>    <span rel="foaf:knows" href="#ivan">
>    <span rel="foaf:knows" href="#shane">
> </div>
> --------
> <#me> foaf:knows <#ivan> .
> <#me> foaf:knows <#shane> .
> -----------------------------------------------------------------
> 

I was not 100% comfortable with that yesterday, and I am still a bit 
ambivalent with it. My problem is that @href in the <div>: would that 
also lead to spurious triples if, for example, I use <a> instead of the 
<div>? Hm. Maybe not... (not sure here, as you can see).

Another slight problem I see is: say a person has the following code 
somewhere:

<span property="a:b" content="something" rel="b:c" resource="#d">bla</span>

Which would yield

<> a:b "something" ;
    b:c <#d> .

However, *for html reasons*, so to say, we want to enclose that into a 
clickable link which, a priori, has nothing to do with RDF. What happens is

<a href="SOMEURI"><span property="a:b" content="something" rel="b:c" 
resource="#d">bla</span></a>

which makes perfect sense for the HTML author. However, if we use those 
rules, than we get

<#SOMEURI> a:b "something" ;
    b:c <#d> .

and to get the resources unchanged, the user has to think of adding

<a href="SOMEURI" resource=""><span property="a:b" content="something" 
rel="b:c" resource="#d">bla</span></a>

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...

Ivan


> and this is where the two models differ (note that @rel was moved up to
> the containing element and the href is changed to @about):
> 
> -----------------------------------------------------------------
> <div about="#me" rel="foaf:knows">
>    <span href="#ivan">
>    <span resource="#shane">
> </div>
> -------- Approach A triples (Mark)
> <#me> foaf:knows <#ivan> .
> <#me> foaf:knows <#shane> .
> -------- Approach B triples (Ben)
> NO TRIPLES GENERATED
> -----------------------------------------------------------------
> 
> If you replace each @href/@resource with @about in the second example,
> the two different approaches generate the same triples:
> 
> -----------------------------------------------------------------
> <div about="#me" rel="foaf:knows">
>    <span about="#ivan">
>    <span about="#shane">
> </div>
> -------- Approach A triples (Mark)
> <#me> foaf:knows <#ivan> .
> <#me> foaf:knows <#shane> .
> -------- Approach B triples (Ben)
> <#me> foaf:knows <#ivan> .
> <#me> foaf:knows <#shane> .
> -----------------------------------------------------------------
> 
> -- manu
> 

-- 

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