- From: Ivan Herman <ivan@w3.org>
- Date: Fri, 14 Sep 2007 11:14:17 +0200
- To: Ben Adida <ben@adida.net>
- CC: public-rdf-in-xhtml-tf@w3.org
- Message-ID: <46EA50E9.5070406@w3.org>
Hi Ben, I think we are at the point that whatever we define, there will be awkward edge cases. I think we are at the point where it is more important to finalize and document things and then let the community decide. Bottomline: I do not have any problem with your analysis, but I have an algorithmic mind these days, so I try to translate what you say in the processing steps (I hope I did it right). Trying to extend my processing rule descriptions in [1], I guess what you are saying is: Case 4: (trying to formulate a bit what Ben describes) 1. [current object resource] is calculated in all cases 2. @rel and @rev attributes are used to generate triples 3. If - (@instanceof is present but @about/@rel/@rev/@resource aren't), or - if any triples are generated in step #2 then [current resource] = [current object resource] 4. @instanceof attributes are used to generate triples; the subject of the rdf:type triples are [current resource] 5. recursion happens with [current resource] Which is a slight modification on what I had as case (2) in [1]. <div instanceof="a:b"><span property="c:d">bla<... -> _:x rdf:type a:b; c:d "bla". <div about="#q" instanceof="a:b"><span property="c:d">bla<... -> <#q> rdf:type a:b; c:d "bla". <span about="#paul" rel="foaf:depiction" resource="http://picture.of/PaulWalsh" instanceof="foaf:Person" property="foaf:name">Paul Walsh</span> -> <#paul> foaf:name "Paul Walsh"; foaf:depiction <http://picture.of/PaulWalsh>. <http://picture.of/PaulWalsh> rdf:type foaf:Person. Ie, we have alternatives (1) (2) (3) and (4). I think alts (3) and (4) are the closest to what we have. Both have some 'exceptional' clause in them regarding instanceof. Both can be explained in human terms as: - Alt 3: The subject of @instanceof on an element is either @about, if present. In other cases the subject is the @resource/@href/@src values if any of those are present or an extra blank node. In all cases, the subject of the child element is the subject of @instanceof. - Alt 4: The subject of @instanceof on an element is whatever the subject of a child element would be by normal inheritance. If @instanceof appears in the element without @about/@rel/@rev/@resource, then a blank node is generated as a subject of @instanceof, which will become the inherited subjects for the child elements. I must say that I can live either way. Alt 3 gives a nicer result on the complex example of Mark (see above and [1]), Alt 4 is slightly more consistent. I see more 'edge' cases with Alt 4 which we have to define: what does it means "@instanceof by itself". What is then the relationships with @src, @href? I have tried to look at a number of additional edge cases to see what happens <span about="#a" instanceof="a:b" rel=""> -> <#a> rdf:type a:b. # Both cases, @rel does not generate # triples because it is empty <span instanceof="a:b" href="urn:bla"> -> <urn:bla> rdf:type a:b. # Alt 3 _:x rdf:type a:b. # Alt 4, @instanceof by itself or <urn:bla> rdf:type a:b. # Alt 4 if '@instanceof by itself' is not # true with @href present (this is not # the case up there...) <span instanceof="a:b" href="urn:bla" rel=""> -> <urn:bla> rdf:type a:b. # Alt 3 _:x rdf:type a:b. # Alt 4 Alt 3 gives a nicer result on the complex example of Mark (see above and [1]), Alt 4 is probably more consistent (in spite of that extra rule). I can live either way, it should be finalized, though. Ivan [1] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Sep/0097.html Ben Adida wrote: > > Ivan, Mark, and everyone, > > I had an action to explain my point of view on this thorny @instanceof > issue. I was late in doing this, so of course the discussion began > without me, which is healthy :) > > That said, I want to return to basic principles and explain why my point > of view differs from Mark's on the complicated use case. I don't want to > talk about parsing rules yet. I want to talk about what *should* happen > in the simple cases, and then argue about what makes sense in the more > complicated case. > > I think we agree that > > <div about="#mark" instanceof="foaf:Person"> > </div> > > and > > <div href="#mark" instanceof="foaf:Person"> > </div> > > both correspond to > > <#mark> rdf:type foaf:Person . > > > We also agree that: > > <div instanceof="foaf:Person"> > </div> > > corresponds to > > _:div0 rdf:type foaf:Person . > > We also agree that: > > <div about="#mark" rel="foaf:knows" href="#steven"> > </div> > > corresponds to: > > <#mark> foaf:knows <#steven> > > > So the question is, what happens when you add @instanceof to the above > example? Does it apply to @about or @instanceof? > > By construction, you can go down two paths and come up with two > different results. So I don't think the construction approach helps. > Instead, I prefer to think about the meaning of @instanceof: > > The "@instanceof is a child element" argument: > > @instanceof is sugar for a child LINK element, back when we > supported LINK (here I agree with Mark). Introducing @href > (or @resource) overrides the subject for all child elements. > Thus, @instanceof applies to @href. > > Mark is worried about how one would apply a type to the @about. I don't > think that's too difficult: > > <div about="#mark" instanceof="foaf:Person"> > <div rel="foaf:knows" href="#steven"> > </div> > </div> > > In fact, I don't think we should *ever* recommend the use of @about, > @rel, @href, and @instanceof on the same element. We just need to > *handle* it when authors write it. And by the "@instanceof is a child > element" argument above, I think it has to apply to @src/@href/@resource. > > So the parsing rule for @instanceof is: > > The subject of @instanceof on an element is > whatever the subject of a child element would be > by normal inheritance. > > One last thing: how do we handle @instanceof by itself? We add an > additional processing rule, which is that @instanceof triggers chaining > as if there had been a @rel on the element, only there is no @rel so > there is no "parent triple". > > -Ben > -- 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 Friday, 14 September 2007 09:14:16 UTC