Re: Error in test or error in spec?

On Mar 7, 2012, at 5:53 PM, Niklas Lindström wrote:

> Ah, yes, I remember that. And now I also recall [1]. Apparently, this
> discussion and its conclusion has happened before. ;)

How soon we forget :P.

Gregg

> Best regards,
> Niklas
> 
> [1]: http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Feb/0012.html
> 
> 
> 2012/3/8 Gregg Kellogg <gregg@kellogg-assoc.com>:
>> Okay, mystery resolved. I found the original email thread [1] where I had pointed out and argued for the behavior that I actually implemented. As Ivan said, it comes down to a judgement call, it I don't think I made the case at the time, but never reversed the implementation in my code.
>> 
>> This will likely affect a number of joint RDFa 1.0/1.1 tests cases, as Ivan pointed out, in which case I agree that we should make equivalent test cases, where appropriate, for RDFa 1.1 behavior; it sounds like Ivan has a start on that.
>> 
>> Gregg
>> 
>> [1] http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Nov/0074.html
>> 
>> On Mar 7, 2012, at 4:39 PM, Niklas Lindström wrote:
>> 
>>> Hi guys,
>>> 
>>> I was actually dealing with this very thing last night, and wondered
>>> if there were some kind of "implicit @about" going on due to hanging
>>> rels (other than the "parent subject"), affecting @typeof, which kind
>>> of spooked me. So I'm glad to see Ivan's analysis, since it seems to
>>> validate my gut feeling about it. As far as I can see, Ivan is
>>> absolutely right that the processing rules has this effect. I also
>>> agree that this should probably be how it is, as I am as wary as Ivan
>>> about complicating things. (That is, I believe that a hanging rel
>>> should only affect the generation of links to nested subjects, it
>>> shouldn't affect how nested RDFa itself is parsed.)
>>> 
>>> Best regards,
>>> Niklas
>>> 
>>> P.S. In case anyone's curious, my Clojure implementation is slowly
>>> closing in on the last bits of hanging rels. Soon the only things
>>> remaining are host-language specifics (e.g. implicit about in head and
>>> body) and some syntax stuff (XML-literals, relative terms and empty
>>> CURIEs). It's all purely functional (well, apart from bnode
>>> generation), including the @inlist parts. :)
>>> 
>>> 
>>> On Wed, Mar 7, 2012 at 8:17 PM, Ivan Herman <ivan@w3.org> wrote:
>>>> Gregg,
>>>> 
>>>> I am not on my machine right now, so I cannot really check things in details. But... the point is that the current behaviour is consistent with the pattern that we took from the various schema.org examples, ie
>>>> 
>>>> <bla property="prop" typeof="sometype">...
>>>> 
>>>> which results in a blank node object for the @property which will also be chained. If we began to fiddle around with this depending on whether we have some hanging rels coming in to the element, essentially the blank node being suddenly the subject for @property instead of the object, that would be sooooo messy that I do not think we should go there. I would be of the opinion to stay where we are, the spec is o.k., and adapt our tests...
>>>> 
>>>> My two cents on a Wednesday evening...
>>>> 
>>>> Ivan
>>>> 
>>>> ---
>>>> Ivan Herman
>>>> Tel:+31 641044153
>>>> http://www.ivan-herman.net
>>>> 
>>>> (Written on mobile, sorry for brevity and misspellings...)
>>>> 
>>>> 
>>>> 
>>>> On 7 Mar 2012, at 19:17, Gregg Kellogg <gregg@kellogg-assoc.com> wrote:
>>>> 
>>>>> On Mar 7, 2012, at 3:24 AM, Ivan Herman wrote:
>>>>> 
>>>>>> Small remarks...
>>>>>> On Mar 7, 2012, at 11:11 , Ivan Herman wrote:
>>>>>> 
>>>>>>> This is what the CR phase is good for: reveal corner cases!
>>>>>>> 
>>>>>>> A simplified version of test #58 looks as follow (simplified, because in the original tests there were two, structurally identical foaf:Person statements, but it is unnecessary here):
>>>>>> 
>>>>>> Oops, sorry, I did not do any change after all:-)
>>>>>> 
>>>>>>> 
>>>>>>>  <div about="http://www.example.org/#ben" rel="foaf:knows">
>>>>>>>    <p typeof="foaf:Person" property="foaf:name">Mark Birbeck</p>
>>>>>>>    <p typeof="foaf:Person" property="foaf:name">Ivan Herman</p>
>>>>>>>  </div>
>>>>>>> 
>>>>>> 
>>>>>> [snip]
>>>>>> 
>>>>>>> 
>>>>>>> My conclusion for now: the test is wrong. We should redo altogether
>>>>>> 
>>>>>> To be more precise: we should do a new test for the RDFa 1.1 case and keep the old one for the RDFa 1.0 case!
>>>>> 
>>>>> I do see some code in my processor which is inconsistent with Step 5, I wonder if something went missing at some point?
>>>>> 
>>>>> 1) In 5.1, if @about defines a new subject, then @typeof should create a typed_resource based on that subject, and not a new BNode.
>>>>> 2) My code skips step 5.1 if there are incomplete triples, which there are in this case, so I proceed to step 5.2, which creates new_subject as a new BNode, and sets typed_resource to that BNode.
>>>>> 
>>>>> I don't have access to the RDFa Core 1.1 CVS history, so I can't tell if this was something that was added and then lost in a subsequent edit. It seems to make sense that we would have considered the case where incomplete triples are created as having an effect on the treatment of @typeof creating a new BNode, or applying to the chained subject evidenced by the incomplete triples.
>>>>> 
>>>>> I can see that I explicitly added the check for incomplete triples on November 11th, just after we adopted the behavior; perhaps it was something we discussed but did not formalize? I admit to being somewhat fuzzy on the topic.
>>>>> 
>>>>> Basically, these are the steps my processor takes:
>>>>> 
>>>>> root>body>div Step 6: new_subject => <http://example.org/#ben>
>>>>> root>body>div Step 10: incompletes => rels: foaf:knows
>>>>> root>body>div>p[0] Step 5: new_subject => _:a (parent object), typed_resource => _:a
>>>>> root>body>div>p[0] Step 7: typeof => foaf:Person => {_:a a foaf:Person .}
>>>>> root>body>div>p[0] Step 11(1.1) => plain literal => {_:a foaf:name "Mark Birbeck"}
>>>>> root>body>div>p[0] Step 12 => complete incompletes => {<http://example.org/#ben> foaf:knows _:a}
>>>>> root>body>div>p[1] Step 5: new_subject => _:b
>>>>> root>body>div>p[1] Step 7: typeof => foaf:Person => {_:b a foaf:Person .}
>>>>> root>body>div>p[1] Step 11(1.1) => plain literal => {_:b foaf:name "Ivan Herman"}
>>>>> root>body>div>p[1] Step 12 => complete incompletes => {<http://example.org/#ben> foaf:knows _:b}
>>>>> 
>>>>> which results in output that is more consistent with RDFa 1.0:
>>>>> 
>>>>> <http://www.example.org/#ben> foaf:knows
>>>>>    [ a foaf:Person; foaf:name "Mark Birbeck"],
>>>>>    [ a foaf:Person; foaf:name "Ivan Herman"] .
>>>>> 
>>>>> Gregg
>>>>> 
>>>>>> Ivan
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> because, of course, with those values it looks weird and, I guess, the goal was to use it as a test for hanging rels:
>>>>>>> 
>>>>>>> <div about="http://www.example.org/#ben" rel="foaf:knows">
>>>>>>>    <p typeof="foaf:Person"><span property="foaf:name">Mark Birbeck</span></p>
>>>>>>>    <p typeof="foaf:Person"><span property="foaf:name">Ivan Herman</span></p>
>>>>>>>  </div>
>>>>>>> 
>>>>>>> which indeed results in
>>>>>>> 
>>>>>>> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
>>>>>>> 
>>>>>>> <http://www.example.org/#ben> foaf:knows [ a foaf:Person;
>>>>>>>          foaf:name "Mark Birbeck" ],
>>>>>>>      [ a foaf:Person;
>>>>>>>          foaf:name "Ivan Herman" ] .
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Thoughts?
>>>>>>> 
>>>>>>> Ivan
>>>>>>> 
>>>>>>> 
>>>>>>> ----
>>>>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>>>>> Home: http://www.w3.org/People/Ivan/
>>>>>>> mobile: +31-641044153
>>>>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----
>>>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>>>> Home: http://www.w3.org/People/Ivan/
>>>>>> mobile: +31-641044153
>>>>>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>

Received on Thursday, 8 March 2012 01:04:28 UTC