- From: Mark Birbeck <mark.birbeck@formsPlayer.com>
- Date: Tue, 22 Jan 2008 12:06:01 +0000
- To: "Manu Sporny" <msporny@digitalbazaar.com>
- Cc: RDFa <public-rdf-in-xhtml-tf@w3.org>
Hi Manu, On 22/01/2008, Manu Sporny <msporny@digitalbazaar.com> wrote: > > Ben Adida wrote: > > I note that you were recently quite unhappy with the possibility that > > @instanceof would apply to @href/@resource (which is reminiscent of my > > proposal). Have you changed your mind? > > I'm still unhappy about @instanceof applying to @href/@resource, but see > it as a possible solution to your, and possibly Mark's, "logical > consistency problem". If we have @instanceof apply to @href/@resource, > we create a new "complicated for XHTML developers" problem. I'm not trying to *add* something here; I drew attention before Xmas to the fact that with generic chaining rules (i.e., the rules I'd proposed) there were certain formulations that looked a bit odd, but that were legal. I asked whether there was any good reason to *prevent* them, and have been trying to point out that preventing some of these formulations from generating triples actually makes things inconsistent. So let's say that we agree that we really want to _inhibit_ the effect of @instanceof on @resource and @href. I don't at all accept that there is a "complicated for XHTML developers" problem -- people don't need to use these formulations if they don't want to, and anyone writing a 'beginners guide to RDFa' that uses these formulations in the first paragraph deserves severe punishment :) -- but let's put aside why we might prevent @instanceof applying to @resource and @href, and focus on how it might be achieved. Well the first and easiest way is to say that @resource and @href don't act like subjects for nested statements...they don't act like subjects at all. I think we've all agreed that being able to set the context for nested statements is desirable, so we'll rule that option out. The second way is to say that @resource/@href only set the subject for contained triples, but not for any predicates on the same element. That means that whilst this generates what the author wants: <div resource="#ben"> <span property="foaf:name">Ben</span> <span rel="foaf:knows" resource="#mark" /> </div> the @property/@content pair should be ignored here: <div resource="#ben" property="foaf:name" content="Ben"> <span rel="foaf:knows" resource="#mark" /> </div> That seems overkill -- unnecessary and confusing -- since why would we _not_ allow it? It's a fairly basic optimisation to move a predicate from the nested position to the element itself, and it looks odd to allow it with @about, but not with @resource or @href. So the third option would be to say that @resource and @href can set the subject for contained statements, _and_ can even set the subject for predicates on the same element, but they don't set the subject for @instanceof. That's the route you seem to be proposing: > [...] > RDFa Syntax Document, Section 5.3.2.4: > ---------------------------------------------------------------------- > CURRENT TEXT: > The [current element identifier] is set to the value of @about, if > present, or the value of @resource, if present, or the value of @href, > if present, or the value of @src, if present, or a [blank node]. > > PROPOSED TEXT: > The [current element identifier] is set to the value of @about, if > present, or the value of @src, if present, or a [blank node]. > ---------------------------------------------------------------------- But now that means that @instanceof will generate a bnode, giving us two possible subjects on the element; if we accept my reasoning above, that @resource should set the subject for @property, then that gives you one subject, and if we accept your reasoning, that @instanceof defines a bnode, then that gives us a second subject. Which should @property bind itself to? Which should be used for any nested statements? The only way to get what you want is to simply ignore the @instanceof attribute altogether when @resource or @href is present, but when there is no @rel. That's quite a rule! Although it's true that an attribute can have no effect in our current processing rules, the only time that happens is if another attribute that plays the same role has a higher priority (@src, @resource, @href, for example). But we don't have any rules that say an attribute has absolutely *no* effect on the triples generated if there is some other combination of attributes present. I'm certainly not sure how I'd write that, but either way, hopefully you can see that to say that @instanceof does not apply to @resource would take more than what you have written above. To be 100% clear, what you have above says that @instanceof should not take its subject from @resource or @href, but that doesn't prevent it from generating a bnode. You could say that this is what you wanted anyway, which means that we'd need to rewind my previous logic, and say that @property does not attach itself to @resource or @href. But that causes problems when we try to merge this: <div instanceof="foaf:Person" property="foaf:name"> Manu </div> which gives: _:a rdf:type foaf:Person . _:a foaf:name "Manu" . with this: <div resource="#manu"> <div rel="foaf:knows" resource="#ben" /> </div> which gives: <#manu> foaf:knows <#ben> . Although we get this: <div resource="#manu" instanceof="foaf:Person" property="foaf:name" content="Manu" > <div rel="foaf:knows" resource="#ben" /> </div> this mark-up no longer yields the merge of the two graphs; I would expect this: <#manu> rdf:type foaf:Person . <#manu> foaf:name "Manu" . <#manu> foaf:knows <#ben> . since all that has changed is that we have given a name to the unnamed subject. But to follow through the proposals for @instanceof not operating on @resource, if we agreed to 'ignore' @resource when @instanceof is present (and there is no @rel), then we get the bnode version: _:a rdf:type foaf:Person . _:a foaf:name "Manu" . _:a foaf:knows <#ben> . But 'ignoring' @instanceof when @resource is present (and there is no @rel), is no better; we get the named version, but we lose the type: <#manu> foaf:name "Manu" . <#manu> foaf:knows <#ben> . I believe that either route is confusing for authors ("why are some attributes ignored when used in certain combinations?"), and it makes the processing rules more difficult to write. And it's quite difficult to see what exactly the gain is, when it's quite straightforward to process *all* of the attributes in a consistent way, by saying that @resource and @href set the subject for both @property and @instanceof. 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 12:06:18 UTC