Re: moving forward!

Ivan,

thanks for your reply.


> > B. Furthermore, I'm uncertain about what the resulting state should be
> > when @rev is used? Consider:
> >
> >    <div about="#something" rev="dct:hasPart" resource="">
> >
> > which AFAIK yields:
> >
> >    <> dct:hasPart <#something> .
> >
> > But what will the subject be for nested content? <#something> or <>?
> > Compare with this:
> >
>
> I think Ben's rules are clear on that: subject of nested content will be <>:
>
> [[[
> the subject of an element's *content* is the element's corresponding
> RDF identity when @rel, @rev, @href, @resource, or @instanceof appears.
> Otherwise, it's @about resolution.
> ]]]
>
> And the RDF Identity is the value of @resource.

Yes, I now see that this is the reasonable thing.


> >    <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 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=""/>

, or perhaps even (not so beautiful I guess):

    <div id="somepart" about="" rel="dct:hasPart" resource="#somepart">

Which is fine, sure. I would have preferred to get away "DRY", without
repeating the fragment name in @about. Given that this seems undoable
here, it may be that I no longer see the same need to use @id in some
cases at all. But that is something I need to contemplate further.

Note 1: I know that there is the possibility of @instanceof "saving
me" in this. In my real use cases so far that would do just fine. But
I can imagine other cases where one does not need/want to type the
component fragment but still use it as I described.

Note 2: IIRC, the old possibility of using a link element here would
have eliminated the need for the @about. But with such a weak effect
(no striping) that I really didn't see it as that useful anyway. I'm
perfectly happy with link and meta no longer in the body. Striping
seems much more sound.


> >
> > 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.

(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)?

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.


Best regards,
Niklas

Received on Thursday, 26 July 2007 12:36:00 UTC