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

Mark,

I must admit I loose track here, and I cannot always see where you are
going.

Could you help out in writing down *exactly* the processing rules for
@instanceof, the way we did it until now and the way it is in the
current draft (or my slightly modified version thereof)? The current
setup (whether the documented one or the one with my small modification)
has the merit of being clear and is not very spagetti like. Can you
modify it so that it would still be concise enough? I am afraid it is
not 100% sure from your mail in which direction you are going...:-(

Ivan

P.S. It is evening, and I call it a day. I may look at this again
tomorrow morning...



Mark Birbeck wrote:
> 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
>>
>>
> 
> 

-- 

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