Re: Thoughts on @href/@resource completing hanging @rels

First of all: my apologies to Mark. He proposes below not to discuss the 
issue further but put it to vote instead, and here I am doing exactly 
what he does not want:-(

However... What I would like to do is to jot down my thoughts, not 
really arguing for one approach or the other. It helped me clarifying 
some of my thoughts, maybe it helps somebody else...

Reading through all the mails, I realized that I can reformulate my 
'mental model' in a slightly different manner. Ie, in Mark's 'complete' 
chaining rules there is _no_ difference (except for syntax on whether 
they use URI or protected CURIE) between @about, @resource, @href, and 
@src. The only issue at hand is *their relative priority*.  All these 
attributes can set object and/or subject. If there is only one, it sets 
the subject; if there are two of them, the higher priority sets the 
subject, next in line sets the object; if there are three of them then, 
well, the third looses out:-). (And then there are rules on which value 
goes 'down' the chain.) In fact, the reasons we have more than one of 
these animals is because:

- we need at least two to set an object and a subject in the same element
- we inherit some of these from XHTML, namely @href and @src, and we 
decided that we have to adopt them to RDFa, too

Otherwise, these guys are absolutely identical. First of all, is that a 
correct model? That means that, for example

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

yields

<#a> a:b <#c>.

(and <#a> is used to 'plug' possible hanging rels 'upwards' and <#c> is 
the subject for possible, say, @property attributes 'downwards'.) Right?

I also agree with Ben that, if this is the way we go, the only logical 
conclusion is that @instanceof applies to whatever the current subject 
is, regardless of whether it stems from an @about or a @resource or a 
@href or a @src value. After all, these are all, essentially, identical 
attributes! The _only_ extra rule on @instanceof we do have (remember 
the discussion before Xmas) is that if there is nothing else around in 
an element, @instanceof creates an extra blank node for a subject.

I must admit that this model is coherent. However, I am still concerned 
by the examples of Ben. I can attribute them to the fact that @href (and 
@src, but that is less of a problem, probably) plays a dual role. Namely 
we try to adjust its behaviour to RDFa but it also has a totally 
different role for XHTML. Ben's examples reflect the clash on these two 
roles. Manu claim that this is not a problem; Ben claims it is and, I 
must admit, I am not convinced by Manu on that. As before, my primary 
discomfort is (and has always been) with the sudden appearance of 
spurious triples:-(

One more thing. I also realized that the attribute names are very badly 
chosen if we take this model:-( For somebody coming from the RDF/XML 
world, @about and @resource have a clear meaning. And that meaning is 
_not_, as far as I can see, compatible with Mark's model (and it is more 
compatible with Ben's more restrictive model). Indeed, Also, because the 
(English) names are very different, one easily tries to assign them very 
different behaviour whereas, in fact, they are not different. Not sure 
we can do anything about it; finding new attribute names is like finding 
a good abbreviation for a project, it needs a white table, a good meal 
and some glasses of beer:-). But it may be worth remembering that and 
maybe making a note in the primers and tutorials...

I am not sure it helped you guys, but it helped me...

Ivan

Mark Birbeck wrote:
> Hi Manu/Ben,
> 
> I do agree with Manu here, but also I recall that Ivan reached a
> position where he said that this may be less of an issue than he
> thought.
> 
> I'm not trying to put words into his mouth, merely to say that we have
> probably reached a point where we might as well vote, since I'm not
> sure that much more is going to be added to this discussion. So unless
> those who have remained quiet on this issue up until now have points
> they want to raise, then it would certainly save a lot of time if we
> could wrap at least one of these issues up.
> 
> Regards,
> 
> Mark
> 
> On 21/01/2008, Manu Sporny <msporny@digitalbazaar.com> wrote:
>> Ben Adida wrote:
>>> Manu Sporny wrote:
>>>> As for spurious triples in newly created XHTML+RDFa pages, well, there
>>>> is no such thing.
>>> I disagree with this statement quite strongly. People won't write
>>> XHTML+RDFa from scratch. They'll start with XHTML and sprinkle in RDFa
>>> progressively.
>> Then I must strongly disagree with your statement which strongly
>> disagrees with my previous statement :)
>>
>> We all agree that moving XHTML around is a gigantic pain and should be
>> avoided at all reasonable costs... however, I have a large sample set of
>> people proving that folks are quite agreeable to moving their XHTML
>> around when the benefits outweigh the costs:
>>
>> Microformats
>>
>> Additionally, we had to go through and restructure all of our corporate
>> and service websites when we decided to add Microformats to our website.
>> Most of the people I know that have added Microformats to their page
>> (lots) have had to div-span-itize their sites. Most websites generate
>> the XHTML using PHP (or ASP, or Ruby, or <insert web language du jour
>> here>), so, this is not as big of a deal as it may seem.
>>
>> Sure, a couple of our web developers griped that they shouldn't have to
>> move stuff around to make Microformats work... but they did move the
>> XHTML around because the benefits far outweighed the cost of doing so.
>>
>> Besides, as I stated, we never had <div> and <span> tags around the data
>> on our pages... we had to change the XHTML structure just to enable
>> semantics on our pages.
>>
>> Which, like it or not, the vast majority of people adopting Microformats
>> or RDFa will have to do.
>>
>>> They will add a hanging @rel, and if that suddenly forces them to
>>> restructure large chunks of HTML because they can't include plain
>>> images
>>> and links within that chunk, that reflects poorly on RDFa as a whole.
>>> This has already happened with Creative Commons.
>> I very strongly disagree... if adding a hanging @rel screws things up...
>> they'll remove that hanging rel before restructuring their XHTML
>> (because that is the easiest thing to do).
>>
>> Is it really that difficult to tell people that if they start seeing
>> wierd triples generated, that they should move their hanging @rel down
>> to the thing that should be generating the triple?
>>
>> Do you really think that people won't have tools in their browser (like
>> Operator) to check to see if they are generating the proper triples?
>>
>>> That's typically what happens with RDF/XML, btw. Adding a few properties
>>> is easy, but then you start striping and it gets *really* messy, and
>>> many people give up.
>> Seeing the number of people struggling to mark up very complex use cases
>> using Microformats tells me that people don't give up that easily.
>> Rather, the people that give up must not have much to gain by marking up
>> their data using Microformats OR RDFa.
>>
>> I think that we shouldn't forget that chaining is an advanced RDFa
>> concept and thus, has some complex issues that come along with it. Those
>> complex issues are very easy to address:
>>
>> Either you
>>   a) don't use hanging @rels, or
>>   b) understand that @about/@href/@resource completes hanging @rels.
>>
>> The paragraph above is quite easy to express and understand - meaning it
>> can be taught quite easily. If we turn this into an education problem
>> instead of a language problem, we simplify teaching, developing and
>> using RDFa. It is a good trade-off, IMHO.
>>
>> -- manu
>>
>> --
>> Manu Sporny
>> President/CEO - Digital Bazaar, Inc.
>> blog: Intro to the Semantic Web in 6 minutes (video)
>> http://blog.digitalbazaar.com/2007/12/26/semantic-web-intro
>>
>>
> 
> 

-- 

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 Tuesday, 22 January 2008 13:06:25 UTC