- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 12 Sep 2007 12:52:44 +0200
- To: Mark Birbeck <mark.birbeck@formsPlayer.com>
- Cc: "public-rdf-in-xhtml-tf.w3.org" <public-rdf-in-xhtml-tf@w3.org>, Ben Adida <ben@adida.net>
- Message-ID: <46E7C4FC.6000607@w3.org>
Mark,
(I think that there is one general conclusion of this and similar
discussions we all had in the past: in any setting there are cases which
lead to somewhat awkward RDFa coding.:-( Let alone the fact that what is
awkward and what is not is often a personal opinion... We have to live
with that.)
I tried to see how to modify the processing steps to, maybe, encompass
most of the cases. I am uneasy making any drastic change on the whole
processing at this point, though, so even with these there might be edge
cases that do not really fit. But I tried to keep the changes to the
strict minimum. I think we should write down what we have, publish it,
and let the community give its feedback whether it can live with it or
not... (That is the beauty and strength of the W3C process...)
With that preamble, and for an easier comparison, I have described three
alternatives in the processing steps (well, the relevant part only for
@instanceof). I look at the effect of two cases that are somewhat edge
cases as well as your more complex example. The two edge cases are:
<div instanceof="a:b"><span property="c:d">bla<...
<div about="#q" instanceof="a:b">
I also looked at what the outcome of
<span about="#paul"
rel="foaf:depiction"
resource="http://picture.of/PaulWalsh"
instanceof="foaf:Person" property="foaf:name">Paul Walsh</span>
is.
It seems that Case 3 covers these edge cases, and works. My vote goes
for that one. The only caveat is, somewhat philosophically, that the
choice of the subject on the rdf:type triples is not necessarily the
'inherited' subject via the @about chain like for other things. Oh well,
we can't get it all...
It would be good if we could make a choice among those three, and then
live with the consequences, so to say:-).
Ivan
----------------------------------------------------
Case 1: (version documented as of now in [1])
1. [current object resource] is calculated in all cases
2. @rel, @rev and @instanceof attributes are used to generate triples;
the subject of the rdf:type triples are [current object resource]
3. If any triples are generated in step #2, [current resource] =
[current object resource]
4. recursion happens with [current resource]
<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<...
->
_:x 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.
---
To create
<#q> rdf:type a:b;
c:d "bla".
one needs, eg:
<div about="#q">
<span rel="rdf:type" resource="FULL URI FOR a:b"/>
<span property="c:d">bla...
(or put the instanceof somewhere else in the file, with a resource="#q",
if appropriate)
----------------------------------------------------
Case 2: (version I proposed in [2])
1. [current object resource] is calculated in all cases
2. @rel and @rev attributes are used to generate triples
3. If any triples are generated in step #2, [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]
<div instanceof="a:b"><span property="c:d">bla<...
->
<#> 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.
To create
_:x rdf:type a:b;
c:d "bla".
One need: I DO NOT KNOW!:-(
----------------------------------------------------
Case 3: (trying to formulate a bit what Mark describes)
1. [current object resource] is calculated in all cases
2. @rel and @rev attributes are used to generate triples
3.
3.1 if [current element] includes the @about attribute then
@instanceof attributes are used to generate triples; the subject
of the rdf:type triples are [current resource]
3.2 @instanceof attributes are used to generate triples;
the subject of the rdf:type triples are [current object resource]
3. If any triples are generated in step #2 or #3.2, [current resource] =
[current object resource]
5. recursion happens with [current resource]
<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>;
rdf:type foaf:Person.
[1] http://www.w3.org/MarkUp/2007/ED-rdfa-syntax-20070906/#s_model
[2] http://www.w3.org/mid/46E3D699.8090309@w3.org
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
Received on Wednesday, 12 September 2007 10:52:42 UTC