Re: moving forward!

[snip]
> 
>> >    <div rel="dct:hasPart" resource="something">
>> >
>> > yielding the same triple as above, and according to the rules clearly
>> > having <#something> as the "nested subject". This becomes even
>> > trickier for me if both @rel and @rev is present, or if @resource is
>> > absent.
>> >
>>
>> I do not really see a problem on the algorithmic level. @rel or @rev do
>> not affect that choice of the RDF Identity...
>>
>> On a user level... well, I always considered @rev as a probably
>> necessary thing but which is/should be used in somewhat exceptional
>> circumstances anyway...
> 
> Indeed, given the above this seems clear too. Also, an absent
> @resource simply means a bnode resource and the same resolution
> algorithm, right?
>

I think so.

> I think my insecurity stemmed from my desire to use @id coupled with
> @rev, to make a relation from the document URI to the fragment URI
> *and* have that fragment URI set as the corresponding RDF identity.
> For now disregarding how @id will finally be used, I had hoped this
> would do it:
> 
>    <div id="somepart" rev="dct:hasPart" resource="">
> 
> But now I see this won't work (corresponding identity will come from
> @resource). That said, even if @id will sometimes be used, I can see
> no way today to achieve what I describe without writing e.g.:
> 
>    <div id="somepart" about="#somepart">
>        <a rev="dct:hasPart" href=""/>
> 

Except that I would probably write something like

<div id="somepart" about="#somepart">
        <span rev="dct:hasPart" href=""/>

to avoid a blue spot on the screen as an active link. Now that @href is
usable on all elements, that is fine; one can also use @resource for the
same purpose, of course.


[snip]

> 
> 
>> >
>> > D. Regarding rdf:type, will this shorthand be a syntactic one based
>> > upon the (above) subject striping rules? As opposed to another
>> > resolution technique possibly directly affecting the striping
>> > algorithm?
>> >
>> > Assuming the former, is the rdf:type attribute (say @instanceof) a
>> > plain shorthand for a child element with @rel="rdf:type" and a
>> > @href/@resource? This must probably be the case, since if it is a
>> > shorthand for putting the @rel etc in the same element, that would
>> > make, by following the current idea of striping, the *type* the nested
>> > subject.
>> >
>>
>> Again, I think Ben's rules are clear on that:
>>
>> [[[
>> the element's corresponding RDF identity is the subject of an rdf:type
>> triple when instanceof appears.
>> ]]]
>>
>> ie, it is _not_ a purely syntactic sugar, but has its own rule of usage.
>> And I have the impression that this fits pretty well our different use
>> cases... Anybody is of course allowed to use a rel="rdf:type" and fall
>> back on the general mechanism (if wished).
>>
> 
> Again, I believe you are right. Then it is a case both depending on
> and affecting striping. Could this rule be that @instanceof (or what
> it will be called) means:
> 
>    - it works as a "corresponding RDF identity determination trigger"
>    - its only part in the resolution is that if no other attribute
> determines identity, a bnode is generated
>    - when that identity has been determined, the rdf:type statement
> is generated
> 
> , or something to that effect? I just want to see the rule spelled out
> explicitly.
> 

Hm. I am not sure it is necessary to spell out the rule differently than
the way Ben did them. I think what you write is actually true, but I am
not sure it would be necessary to write that part down separately...

(Although, I suppose, in a 'primer' setting this may be useful)

> (Similarly, I suppose the @id case *could* be: when a bnode is "about
> to be" generated, the presence of an @id will cause that to be used
> instead.)
> 
> 
>> > E. Finally, for future thought, does it seem reasonable that when this
>> > attribute appears at the root element of a document (or even head in
>> > XHTML), its xml:base (explicit or implicit) will be the subject of the
>> > rdf:type statement? I suppose so (and that this works for either case
>> > here).
>>
>>
>> Hm, that is interesting, but regardless of @xml:base.
>>
>>
>> <html instanceof="foo:bar">
>>
>> would mean, according to Ben's rule that a blank node is created:
>>
>> _:bb rdf:type foo:bar
>>
>> and, from then on, _all_ RDFa statements are relevant to _:bb, ie, this
>> sets the new context. Unless explicitly referred to, <> will never be
>> valid. I am not sure that is bad, but just shows a side-effect of our
>> rules. But I do not see how @xml:base would have an influence on
>> anything...
>>
> 
> You may be right. In any case, I expressed myself poorly. What I meant
> was just the base URI (either the document's implicit URI or set by
> @xml:base), and then I subsequently assumed an implicit @about="" on
> the root element. Which IIRC is assumed for the head in XHTML as well?
> At least it was, to play well with link and meta there. But RDF
> identity resolution may have changed this too (made it unnecessary)?
> 

AFAIK this is what happens already. The @about inheritance rules behave
exactly as if the @about="" was set implicitly on the <html> element.


> If this is a bad assumption, I suggest that the root element is
> considered as setting the corresponding RDF identity (thus making an
> @instanceof refer to that as opposed to causing a bnode appearing). To
> avoid the effect you mention.
> 

I do not consider the effect I mention that dramatic. I would prefer not
to make an exception; if somebody wants to set the rdf:type for "", then
adding a

<span rel="rdf:type" resource="a:b"/>

would do the trick. In general, setting the rdf:type of an element 'up'
in the tree hierarchy would require that sort of trick. I am not sure
that is dramatic (it is a bit like the usage of <link> in earlier versions).

Ivan

> 
> Best regards,
> Niklas

-- 

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