- From: Mark Birbeck <mark.birbeck@formsPlayer.com>
- Date: Tue, 22 Jan 2008 14:24:10 +0000
- To: "Ivan Herman" <ivan@w3.org>
- Cc: "Manu Sporny" <msporny@digitalbazaar.com>, "RDFa mailing list" <public-rdf-in-xhtml-tf@w3.org>, "Ben Adida" <ben@adida.net>
Hi Ivan, This was indeed useful...thanks. :) > [...] > 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. That's correct. Note that this is a _consequence_ of applying chaining rules consistently, rather than an initial design goal. I.e., it stems from the fact that a resource could be the subject of a statement, or the object of a statement, or both a subject and object at the same time. > 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:-). Ah...not quite. I would say that the only issue is what happens when you put a @rel or @rev on the same element as one of these 'generic' attributes. Until you do that, they will all exhibit the object/subject features you mention. But once they come into contact with @rel, they have to go to one side or the other -- they have to either be a subject in relation to that @rel, or an object. This doesn't mean that they lose their generic object/subject-ness -- it just means that if they go to the left of @rel and become its subject, they will simultaneously be an object for any statements 'above'. And if they go to the right of @rel and become its object, they will simultaneously be a subject for any statements 'below'. Pictorially, I see it like this. The 'generic' layout is like this, with all of the middle resources being object/subjects, and of course the first resource being a subject, and the last an object: resource | | predicate | | resource | | predicate | | resource This chain can go on forever, but if you put a predicate on the same line as the subject and object it connects, then obviously one resource has to go to the left (subject), and one has to go to the right (object): resource | | predicate | | resource--predicate--resource | | predicate | | resource So the priority question applies only to the situations when there is more than one attribute that could play a role. You could represent that pictorially, like this: | | | | | @about | | @resource | | | | | | @src | @rel | @href | | | | | | bnode | | bnode | | | | | This shows that all attributes must go to the right or left of @rel, and also illustrates their pecking order within their respective positions. (I'm putting @src on the left only to fill the list up and show priorities. I realise that the decision has not yet been made on where it should go.) > (And then there are rules on which value > goes 'down' the chain.) Actually there is only one rule, the object/subject sets the context for any children. So, if there is no @rel then we're dealing with one of our generic object/subject attributes, so that will provide the object for any parent statements, and the subject for any children. And if @rel is present, the resource to the left of @rel becomes a subject/object, whilst the resource to the right remains an object/subject. Then all we do is to follow the priority rules in the box above to work out what the value of the right-hand side of @rel is (the object for @rel), and then that is the subject for any nested statements. > 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 Yes. > - we inherit some of these from XHTML, namely @href and @src, and we > decided that we have to adopt them to RDFa, too Yes, exactly. :) > Otherwise, these guys are absolutely identical. First of all, is that a > correct model? Do you mean 'have I (Ivan) understood your (Mark's) model correctly?' If so, I'd say that you definitely have, except for the point about prioritisation; I'm saying that in the presence of @rel, the attributes have to take on the subject-role to the left, or the object-role to the right, but they will always go the same way in relation to @rel, irrespective of what other attributes are on the element. But if you mean 'is such a model wise?' then obviously that's a rhetorical question, so I can't answer it. :) > That means that, for example > > <div resource="#a" rel="a:b" href="#c"/> > > yields > > <#a> a:b <#c>. No. In this case, applying the grid above, you would get: _:a a:b <#a> . I.e., both @resource and @href shift to the right in the presence of @rel, and then according to our list, @resource takes priority. > (and <#a> is used to 'plug' possible hanging rels 'upwards' and <#c> is > the subject for possible, say, @property attributes 'downwards'.) Right? Right concept, but the bnode would 'plug' upwards (it becomes a subject/object) and <#a> sets the subject 'downwards' (it becomes an object/subject). > 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! Right. Good. Although there is a separate thread for that debate, so it might be worth mentioning that there, just in case it gets lost. > 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 thought that was resolved...do you think it's not? Or are you just pointing out that we mustn't forget to include it? According to the grid, whether @instanceof gets to create a bnode or not depends on the presence or not of one of the attributes that is above it in the list (@about and @src). > 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. Yes, I agree. I'd be really pleased if we were able to accept that although some of the formulations we have been playing with 'look' quirky, for consistency's sake we should support them (@resource and @href as subject, @instanceof applying to @resource and @href, and so on). That would leave the problem you refer to as something in its own right, and as you correctly say it relates to the tension we will inevitably have between attributes that were intended for one purpose, being used for another. We can then debate that one issue and give it the attention it deserves. > 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:-( I think the argument being put forward is that an author is not going to get "spurious" triples, if they know the rules. My suggestion would therefore be that we don't bother too much with that argument. (For example, do I get "spurious" triples if I use @rel="next"? Only if I didn't know that its use generated a triple.) That doesn't mean that there is no argument, and I think a stronger one is one that you raised before, that it is difficult to use <a> merely to represent a clickable link, with no concern as to how it effects RDFa. I'm not saying I have a solution, but I think that is the real core of the problem. > 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. Which of course is no coincidence. :) In my very early drafts I actually had this: <div rdf:about="s"> ... </div> > 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). I think it is compatible, if you bear in mind that all attributes have to go left or right when placed into contact with a @rel. So up until that point, they might as well be called @blob and @blah. But the moment @rel appears on the same element, each attribute must go left or right, and then its name actually gives quite a clear indication of what it does. > 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:-). :) Very true. > But it may be worth remembering that and > maybe making a note in the primers and tutorials... Yes. Definitely. > I am not sure it helped you guys, but it helped me... I think it was useful...thanks again. Regards, Mark -- Mark Birbeck, formsPlayer mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232 http://www.formsPlayer.com | http://internet-apps.blogspot.com standards. innovation.
Received on Tuesday, 22 January 2008 14:31:20 UTC