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