- 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