Re: Agenda Topic / Issue: Clarify the meaning of "ignore" with respect to attributes that have no legal value

Jeni,

I have comments embedded below:

Jeni Tennison wrote:
>
> On 11 Sep 2009, at 16:36, Shane McCarron wrote:
>> It is my belief that the following are NOT equivalent from a 
>> processing perspective (assume the foaf prefix is declared, the blah 
>> prefix is not):
>>
>>     • <span about="#shane" property="foaf:name" datatype="">Shane</span>
>>     • <span about="#shane" property="foaf:name" 
>> datatype="blah:blah">Shane</span>
>> The first item explicitly requests a text literal.  The second item 
>> requests a datatype that is undefined (illegal, invalid, whatever).  
>> I maintain that in a conforming processor the second item would NOT 
>> generate any triple.
> .....
>
> The next possibility is that it's a plain literal, if it meets any of 
> the conditions:
>
>       • @content is present;
>     • or all children of the [current element] are text nodes;
>     • or there are no child nodes (in which case the literal value is 
> the empty string);
>     • or the body of the [current element] does have non-text child 
> nodes but @datatype is present, with an empty value.
>
> In this case, all children of the current element are text nodes, so 
> the object is a plain literal and the triple should be:
>
>   <#shane> foaf:name "Shane" .
I agree.
>
> In the case where the element did contain elements:
>
>   <span about="#shane" property="foaf:name" 
> datatype="blah:blah"><em>Shane</em></span>
>
> I think the fourth of the clauses -- "or the body of the [current 
> element] does have non-text child nodes but @datatype is present, with 
> an empty value." -- comes into action, because there is a datatype 
> attribute present but it has an empty value (because its value is 
> illegal). So we again get the triple:
>
>   <#shane> foaf:name "Shane" .
(thanks for fixing my example.  that's what I was driving at, but I was 
working too quickly again!) 

And I disagree.  I don't think we SHOULD get that value.  I think 
transforming an explicit datatype that was declared in error into 
another datatype violates the principle of least surprise.  I think that 
in this case, in the default graph, the processor MUST act as if the 
attribute was never there.  Unlike @rel, there are no rules that care 
about the presence of @datatype.  Specifically, I disagree with your 
interpretation that the case of  "@datatype is present with an empty 
value" is equivalent to "@datatype is present with an illegal value". 

> I think the same is true for our treatment of @property, @about, and 
> @resource.  It is explicitly NOT true for @rel, @rev, and (maybe) 
> @typeof because of their ability to cause bnodes to be created.  Do 
> you disagree?  And can you answer in one page or less? :P
>
>
> FWIW, I disagree about property, because it also has the power 
> (through the setting of [skip element] in step 4) to determine whether 
> or not bnodes are created to complete any hanging triples. This is 
> Philip's example. With no property attribute:
>
>   <p xmlns:ex="http://example.org/" about="http://example.com/" 
> rel="ex:rel1">
>     <span content="Content 1">
>       <span about="http://example.net/">Test 1</span>
>     </span>
>   </p>
>
> we should generate:
>
>   <http://example.com/> <http://example.org/rel1> <http://example.net/> .
>
> With a legal property attribute:
>
>   <p xmlns:ex="http://example.org/" about="http://example.com/" 
> rel="ex:rel2">
>     <span property="ex:prop" content="Content 2">
>       <span about="http://example.net/">Test 2</span>
>     </span>
>   </p>
>
> we should generate:
>
>   <http://example.com/> <http://example.org/rel2> _:bnode1 .
>   _:bnode1 <http://example.org/prop> "Content 2" .
>
> The final example being an illegal property attribute which means that 
> the property is still *present* (causing the creation of a bnode) but 
> does not create triples of its own:
>
>   <p xmlns:ex="http://example.org/" about="http://example.com/" 
> rel="ex:rel3">
>     <span property="bogus:bogus" content="Content 3">
>       <span about="http://example.net/">Test 3</span>
>     </span>
>   </p>
>
> we should generate:
>
>   <http://example.com/> <http://example.org/rel2> _:bnode2 .
>
>
I disagree.  I believe it would generate nothing.
> For @about, @resource, @href and @src, the wording is "by using the 
> URI from @{attribute}, if present, obtained according to the section 
> on CURIE and URI Processing;". I think the "if present" here refers to 
> "the URI from @{attribute}" rather than just "@{attribute}", such that 
> if @about does not resolve to a URI there is no value present and it 
> is as if the entire attribute had not been there. So:
>
>   <p xmlns:ex="http://example.org/" about="http://example.com/">
>     <span about="[bogus:bogus]" property="ex:prop">Test</span>
>   </p>
>
> results in the triple:
>
>   <http://example.com/> <http://example.org/prop> "Test" .
I agree with your interpretation, and with the result you show above.
>
>
> It would make things clearer all round if the specification used 
> phraseology that specifically included the possibility of illegal 
> values and made it explicit where it's talking about *values* being 
> present and where about *attributes* being present in relevant places, 
> such as:
>
>   "_the_ @datatype _attribute_ is present, and does not have an empty 
> _or illegal_ value, and is not set to rdf:XMLLiteral."
>
>   "or the body of the [current element] does have non-text child nodes 
> but _the_ @datatype _attribute_ is present, with an empty _or illegal_ 
> value."
>
>   "Additionally, if _the_ @property _attribute_ is not present then 
> the [skip element] flag is set to 'true';"
Quite.  This is why I brought up the issue in the first place.  Or 
rather, Philip did but I am trying to get it resolved.

I know what the spec says, and I respect your opinion about how you are 
interpreting it.  Where we are differing in our interpretation is with 
regard to @property.  The language surrounding @property has been 
confusing to many, including me.  I spend AGES discussing this with Mark 
and Manu and others during the development of the spec and of my example 
implementation.  I am reasonably confident that my interpretation is 
consistent with what we meant when we wrote the spec.

It really comes down to "the principle of least surprise".   If  I 
supply erroneous data, that data should be ignored (at least with 
respect to the default graph).  If data is ignored, then there should 
not be unexpected side-effects from ignoring that data.  Creating a 
bnode because @property="" was defined would be such an unexpected 
side-effect in my mind.

I would be interested in hearing Mark's opinion, but it's late in 
England and if he has any sense he is off with his bride and family for 
the weekend.

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Friday, 11 September 2009 19:41:53 UTC