Re: Issue on the latest syntax document: placement of @instanceof

Hi Ivan,

I expressed pretty much the same sentiment as you, during the telecon
that I referred to in the earlier email. We differ only on whether to
go up the tree to get a subject if none exists. I apologise for not
writing before, but I wanted to get my ideas down as clear as I could
before opening any cans of worms. :)

I find the easiest way to understand @instanceof is to take a 'bottom
up' approach. I think we should regard it as telling us something
about the 'current object', in much the same way that @class tells us
something about the 'current element'. For example:

  <div instanceof="t">
    ...
  </div>

implies to me the creation of a new object and the setting of its
type. All contained properties apply to that object. In other words,
the subject is a bnode, rather than being the most recently nested
@about.

I feel this is very intuitive, since it is a 'mirror' of what HTML
authors already do with @class. It's also very similar to what RDF/XML
authors often do, which is to indicate the type of an object at the
same time as creating a container for its properties--in RDF/XML we'd
often use an XML element:

  <cal:Vevent rdf:about="...">
    ...
  </cal:Vevent>

Note also that the other common way of writing this in RDF/XML is to
put the type declaration right at the top:

  <rdf:Description rdf:about="...">
    <rdf:type resource="http://www.w3.org/2002/12/cal/ical#Vevent" />
    ...
  </rdf:Description>

this is mirrored by the following RDFa:

  <div>
    <link rel="rdf:type" resource="http://www.w3.org/2002/12/cal/ical#Vevent" />

    ...
  </div>

This syntax is not being used in 'RDFa in XHTML' but the general RDFa
pattern still stands, and is used in XHTML 2.

So, if we take as a starting point that @instanceof is very tightly
bound to the 'current object', the next step is to look at what
happens if we obtain a subject from somewhere else. This could come
about via @about, @href, @src or @resource:

  <div about="s" instanceof="t">
    ...
  </div>

  <div href="s" instanceof="t">
    ...
  </div>

  <img src="s" instanceof="t">
    ...
  </img>

  <div resource="s" instanceof="t">
    ...
  </div>

I feel these should all exhibit the same behaviour as the bnode
version; all that has changed is that we now have a name for the
object that we've created. (I increasingly don't like @href and @src
being part of chaining, but we can save that for another time.)

We're then left with the question, what should happen if we have both
@about and one of @resource, @src or @href? My feeling is that to be
consistent with the idea of the type applying to the 'current element'
then it should apply to @about; if you have both @about and @resource
on an element then it's true that the children of the element have
their subject set to the @resouce value as a result of chaining, but
this only happens _after_ you move processing off the 'current
element' and on to the children. Whilst the processing context is
'this element' then the identity of the object should take priority.

This means that the following quite complex construct works perfectly:

  <span
    about="#paul"

      rel="foaf:depiction"
        resource="http://picture.of/PaulWalsh"

      instanceof="foaf:Person"

      property="foaf:name"
        >Paul Walsh</span>

I.e., the _entire_ object is 'a person'.

I'm trying to argue that this is all consistent, but I also think this
kind of construct is far more useful than @instanceof setting the type
of the chained @resource, since it allows you to simply cut and paste
a <span> or a <div> to get an entire 'object', such as a person,
event, etc. Admittedly this 'package' can have a limited number of
predicates predicates, but as you can see here, that's often enough to
express something useful.

So the remaining use-case is when @rel and @instanceof appear on the
same element, but with no object. We _could_ just allow this...by
simply defining a rule that allows it. :) But my feeling is that it
makes for something that doesn't really fit with everything else, and
could actually confuse people.

In the following situation, for example, it seems very awkward:

  <div about="#mark" rel="foaf:knows" instanceof="foaf:Person">
    <span property="foaf:name">Paul Walsh</span>
  </div>

First, it's confusing to read, and second, if @instanceof applies to
the child bnode then it means that there is no way to define the type
of '#mark'. The optimisation achieved seems a pretty small gain, when
in fact all the author needs to do to express this much more clearly,
is this:

  <div about="#mark" rel="foaf:knows">
    <div instanceof="foaf:Person">
      <span property="foaf:name">Paul Walsh</span>
    </div>
  </div>

The extra div makes things much clearer, and we're now able to add
type information for the containing object, if we wanted to:

  <div about="#mark" rel="foaf:knows" instanceof="foaf:Person">
    <div instanceof="foaf:Person">
      <span property="foaf:name">Paul Walsh</span>
    </div>
  </div>

Note that setting type on the child object is all that we lose, since
a @rel with no object can still 'create' an anonymous object:

  <div about="#mark" rel="foaf:knows">
    <span property="foaf:name">Paul Walsh</span>
  </div>

But I don't think you can have everything! Whilst this is a useful way
of creating an 'invisible' anonymous object, it is only useful in a
small set of situations, and I certainly wouldn't recommend it to
people that want to write clear mark-up. So to then start changing the
rules of other attributes to make use of this 'invisible' object, I
believe starts to make things confusing.

Regards,

Mark

On 11/09/2007, Ivan Herman <ivan@w3.org> wrote:
> Ben et al,
>
> I just see that what I write below is _not_ in line what is currently in
> the primer. Indeed, the example in the primer is:
>
> ...<p instanceof="cal:Vevent"
> ...
> ...</p>
>
> which is interpreted in RDF as
>
> _:bn0
>        rdf:type cal:Vevent;
>        ...
>
> indeed, my interpretation below would then yield
>
> <#> rdf:type cal:Vevent;
>
> What this means is that the syntax document and the primer are in line
> (and my implementation is wrong:-). Is this the final decision of the group?
>
> Also, more on the descriptive side, if one has an @about and wants to
> give a type to it, then something more convoluted is necessary:
>
> <span about="#a"><span instanceof="a:b"/></span>
>
> (Is this valid? Ie, can the <span> element be empty?)
>
> Ivan
>
>
> Ivan Herman wrote:
> > My apologies if that was discussed on the telco. I saw in [1] that this
> > issue came up; maybe I am banging on open doors. If so, sorry about that...
> >
> > The question: what is the subject for rdf:type in a construction like:
> >
> > <span about="#a" instanceof="a:b">...
> >
> > Following the Processing steps of
> >
> > http://www.w3.org/MarkUp/2007/ED-rdfa-syntax-20070906/
> >
> > I believe the answer is:
> >
> > [] rdf:type a:b.
> >
> > ie, the subject is a new bnode.
> >
> > Why:
> >
> >  - in step 2, item 1 of the processing steps [current object resource]
> > is set to a new bnode (there is no @href, @resource, etc to set it
> > otherwise)
> >  - in step 3, item 2 of the processing steps triples are generated using
> > the [current object resource] as subject for rdf:type
> >
> > I do not think this is what we want. I think what we want is
> >
> > <#a> rdf:type a:b.
> >
> > Informally, I think what we want to say is that the subject of the type
> > should be [current resource] in case no triples are generated with the
> > [current object resource], and the latter otherwise...
> >
> > Taking into account the problem with chaining, and my proposed changes
> > in [2], this is what I propose for the Processing step
> >
> > - Remove step 2 from processing step 3
> >
> > - Insert a new step between processing step 4 and 5 to set the type
> > values. This is essentially the same text as what was removed from the
> > previous setp, but the type value should be set on [current resource]
> > (an not on [current object resource] as it currently says). Also, the
> > last remark (referring to [chaining]) should be removed.
> >
> > I believe that takes care of the problems.
> >
> > Ivan
> >
> > [1] http://www.w3.org/2007/09/06-rdfa-minutes.html
> > [2]
> > http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Sep/0058.html
> >
>
> --
>
> 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
>
>


-- 
  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, 11 September 2007 14:09:26 UTC