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

Re: thoughts on @resource in current RDFa Syntax draft

From: Ivan Herman <ivan@w3.org>
Date: Thu, 03 Jan 2008 12:41:51 +0100
Message-ID: <477CC9FF.6010109@w3.org>
To: Mark Birbeck <mark.birbeck@formsPlayer.com>
CC: Ben Adida <ben@adida.net>, RDFa <public-rdf-in-xhtml-tf@w3.org>
Hi Mark and Ben.


Mark Birbeck wrote:
> Hi Ben,
> 
> Yes...apologies for missing the call today, but this week turned out
> to be the only time we could get away. Still, my family has been given
> me an hour in an internet cafe...
> 
> :)
> 

Bad idea! You should enjoy your vacations! Hm, well, so should I:-)


> On the issue raised, there are two important aspects to it, but the
> one I'll focus on here concerns consistency in chaining triples
> together. What would you see as being the parsed triples from this:
> 
>   <div about="A">
>     <div rel="p1" resource="B">
>       <div rel="p2" resource="C" />
>     </div>
>   </div>
> 
> I'm assuming we're happy with:
> 
>   <A> <p1> <B> .
>   <B> <p2> <C> .
> 
> What if we split the @rel's and @resource's:
> 
>   <div about="A">
>     <div rel="p1">
>       <div resource="B">
>         <div rel="p2">
>           <div resource="C" />
>         </div>
>       </div>
>     </div>
>   </div>
> 
> Any reason why this should not yield the same triples? I'm hoping not.
> 

I must say that my understanding (and the current status of my
implementation) is currently in line with Ben's and Manu's. And, running
this through my implementation, I get... nothing. No triples. And I
think this is actually al right...

The problem I see is the @href/@resource situation. Remember that @href
and @resource behave almost identically except for the priority and the
usage of CURIE-s (we actually had to discuss whether we would have
@resource at all!). So I would expect you'd assign the same behaviour to
@href, too. But look at the following

<div about="#A" rel="a:b">
   <a href="http://some.where">Something</a>
   <span rel="some:else" resource="#C"/>
</div>

My expectation is that the following would be generated

<#A> a:b [ some:else <#C> ].

However, if I followed your logic, then the

<#A> a:b <http://some.where> .

triple would also be added. My feeling is that this is wrong: the user
uses <a> in the good old way, regardless of RDFa, and through the
approach you have in mind this cannot be done... unless suddenly
@resource has a very different behaviour than @href.

I do not want to comment on the rest of the mail because, I think that
is the crucial issue, the rest somehow may follow.

Ivan



> Now, no-one would bat an eyelid if I rewrote the mark-up like this
> (replacing the middle @resource with an @about):
> 
>   <div about="A">
>     <div rel="p1">
>       <div about="B">
>         <div rel="p2">
>           <div resource="C" />
>         </div>
>       </div>
>     </div>
>   </div>
> 
> and then I'd be free to add some @instanceof's without any complaints:
> 
>   <div about="A" instanceof="t1">
>     <div rel="p1">
>       <div about="B" instanceof="t2">
>         <div rel="p2">
>           <div resource="C" />
>         </div>
>       </div>
>     </div>
>   </div>
> 
> But why can't I add an @instanceof to the last @resource? In
> particular, if we go back one step, and restore the @resource in the
> middle (in place of the @about), why can I not write this example in
> this way:
> 
>   <div about="A" instanceof="t1">
>     <div rel="p1">
>       <div resource="B" instanceof="t2">
>         <div rel="p2">
>           <div resource="C" />
>         </div>
>       </div>
>     </div>
>   </div>
> 
> To rephrase the question--which is how I raised it in the first
> place--how do we _stop_ someone writing this? (And why?)
> 
> Also, given our emphasis on 'cut-and-paste', why shouldn't I be able
> to take the inner block of the prior step and use it somewhere else:
> 
>   <div resource="B">
>     <div rel="p2">
>       <div resource="C" />
>     </div>
>   </div>
> 
> And once again, if I can do that, why not this:
> 
>   <div resource="B" instanceof="t2">
>     <div rel="p2">
>       <div resource="C" />
>     </div>
>   </div>
> 
> My key point is that the RDFa attributes should not be bound hard and
> fast to 'subject' and 'object', since that is meaningless when talking
> of chainingn. Instead their role will depend on their position. But
> what I did say in our prior discussion about @instanceof was that it
> should always apply to the *subject* on an element.
> 
> Note that this is different to the flip-flopping that I was critical
> of in the alternate proposal for @instanceof's behaviour; in that
> situation @instanceof sometimes applied to a subject and sometimes to
> an object, and that caused ambiguities with chaining.
> 
> The reason I see this as an important issue is that if you follow my
> steps above, at which point would we say that something is not
> allowed? Would we say that we can have this:
> 
>   <div about="A">
>     <div rel="p1">
>       <div resource="B">
>         <div rel="p2">
>           <div resource="C" />
>         </div>
>       </div>
>     </div>
>   </div>
> 
> but we can't have this:
> 
>   <div resource="B">
>     <div rel="p2">
>       <div resource="C" />
>     </div>
>   </div>
> 
> If so, that defeats our cut-and-paste goals, and is very inconsistent
> in terms of rules--and gains us nothing.
> 
> Then if we allow @resource to be a subject like @about (which we have
> pretty much already done), why do we prevent it from having
> @instanceof?
> 
> One last point, in terms of complexity for authors I am not at all
> proposing that we advertise these formulations; in just the same way
> that new students of English or Italian are not introduced to the
> subjunctive on day one, so we begin with easy constucts where @about
> and @resource work together. But it's important that the syntax
> document (aimed at parser authors, don't forget), allows these
> 'quirky' constructs so as to ensure complete consistency of the
> language.
> 
> Regards,
> 
> Mark
> 
> 
> 
> On 02/01/2008, Ben Adida <ben@adida.net> wrote:
>>
>> Hi all,
>>
>> Hope the new year is starting well for all! Mark, sorry we won't have
>> you on this week's call. I've taken a look at the latest RDFa Syntax
>> document, and it's coming along *very* well. It's clear, precise, and
>> very useful. Mark, Shane, thanks very much for your work on this. Let's
>> wrap this up ASAP so we can present this to the WG!
>>
>> Now, to one of the issues that Mark brought up before the break and that
>> is reflected in the current syntax draft [1]:
>>
>>>   <img src="A" instanceof="B" />
>>>
>>>   <div about="A" instanceof="B" />
>> I think everyone is in agreement that the above two examples yield
>>
>>   A rdf:type B .
>>
>>>   <div resource="A" instanceof="B" />
>>>
>>>   <a href="A" instanceof="B">label</a>
>> This is where we differ. As Manu mentioned in his response, I don't see
>> this giving the same triple.
>>
>>> I really, really hope that is ok. :) If it isn't then it means we are
>>> going to have to add lots of special cases to our parsing rules, and
>>> that gets quite messy.
>> I think that's not the case. Reading the syntax draft, I think we could
>> take out a chunk and it would fit with Manu's and my interpretation.
>> Specifically, all you need to do is take out the line items on @resource
>> and @href in the [new subject] resolution.
>>
>> (Looking it over again, I think that the current write-up doesn't fully
>> account for the @resource examples above, since @instanceof is processed
>> before @resource and @href. The complete processing rules to support the
>> @resource/@instanceof example might end up being even more complicated.)
>>
>> I think we're dealing with *fewer* special cases and a more intuitive
>> model if we say that [new subject] is resolved as follows in the given
>> priority order:
>>
>>  - @about,
>>  - @src,
>>  - new bnode if @instanceof,
>>  - [parent object] if not null (chaining on explicit object)
>>  - [parent bnode] if not null (chaining on implicit bnode)
>>
>>
>> I don't see newly enabled use cases if we complicate these rules.
>>
>>
>> -Ben
>>
>> [1] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Dec/0125
>>
>>
>>
>>
> 
> 

-- 

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, 3 January 2008 11:41:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:15:20 GMT