Re: [URGENT] Re: RDFa Core 1.1 XML+RDFa spec bug?

This is where we are, I believe:

- I believe (and this seems to what Nathan or Greg also say) that the current spec for XML+RDFa is such that, in the absence of an explicit @about attribute no triples will be generated. Ie

<a>
   <b property="q:r">something</b>
</a>

will generate no triples and the same holds, in my view, for

<a>
   <c>
     <b property="q:r">something</b>
   </c>
</a>

In this sense I do not believe our decision on this week's call was wrong in a _logical/specification sense_. But it is also true that some of the RDFa 1.0 tests, related to SVG, were indeed wrong.

- All that being said, and thinking about it a bit further, I think we indeed made a mistake yesterday with the decision in terms of what the community expectation on this would be. We now formalize/generalize the XHTML+RDFa spec to the more general XML world; in the former case we did define an implicit @about on <body> and <head> and I believe it is a reasonable thing to say that we generalize this instead of the decision we took yesterday. In _that_ sense, that decision was wrong. Manu's proposal is therefore to overturn the decision of yesterday and introduce a rule that says "have an explicit @about=BASE on the top element, unless there is already one" (it is more complicated, I know, but it boils down to that, effectively.) _And I agree with the proposal_.

The current text in the XHTML+RDFa document says:

[[[
In section 7.5, processing step 6, if no URI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or bodyelement. If it is, then act as if there is an empty @about present, and process it according to the rule for @about.
]]]

and the same for 7.6. I would propose to add this to the XML+RDFa language profile except for the fact that this is for the top level element rather than for <head> or <body>. This means that other host languages may define this to be different than others. 

For backward compatibility reasons, however, I do not think we can remove these from the XHTML definition and rely on some generic approach. Indeed

<html about="something">
  <head>
    <meta property="a:b">aaaa</meta>
  </head>
</html>

have to generate

base a:b "aaaa" .

according to RDFa 1.0!

One more reasons to make this language specific, so to say.

Ivan





On Mar 25, 2011, at 10:46 , Nathan wrote:

> Manu Sporny wrote:
>> On 03/24/2011 10:39 AM, Shane McCarron wrote:
>>> I disagree - we say this EXPLICITLY already.  For all contexts. ...
>>> Note that the parent subject is set to the base value.  What am I
>>> missing here?
>> That 'parent subject' has nothing to do with setting the 'new subject'
>> when operating on the root element of the document. However, the 'new
>> subject' is eventually initialized to the 'parent subject' when step #13
>> is hit when processing all elements nested under the root element.
>> We have a problem - and I've verified that problem with Shane, Mark, and
>> Gregg. This is a non-editorial problem, and is a bug with RDFa 1.0. We
>> didn't see the issue until now because the XHTML+RDFa spec masked the
>> problem by setting about="" on HEAD and BODY.
>> However, XML+RDFa 1.1 doesn't do this, but the processing rules will
>> eventually set the 'new subject' to the value of 'base' via this rule in
>> step #13:
>> http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#PS-recurse
>> Specifically, this is run for the root element:
>> """
>> * the base is set to the URI of the document (or another value
>>  specified in a language specific manner such as the HTML base
>>  element);
>> * the parent subject is set to the base value;
>> """
>> and then this
>> """
>> the parent object is set to value of current object resource, if
>> non-null, or the value of new subject, if non-null, or the value of the
>> parent subject of the current evaluation context;
>> """
>> then this is run for the element under the root element:
>> """
>> new subject is set to the URI obtained from the first match from the
>> following rules:
>> ...
>> otherwise, if parent object is present, new subject is set to the value
>> of parent object. Additionally, if @property is not present then the
>> skip element flag is set to 'true';
>> """
> 
> base value = null (initial evaluation context)
> parent subject = base value (initial evaluation context) = null
> parent object = null (initial evaluation context)
> current object resource = null (step 1)
> new subject = parent object (step 6/7) = null
> 
> step 13:
> 
> the parent subject is set to the value of new subject, if non-null, or the value of the parent subject of the current evaluation context;
> = null
> 
> the parent object is set to value of current object resource, if non-null, or the value of new subject, if non-null, or the value of the parent subject of the current evaluation context;
> = null
> 
> all the values are set to null.
> 
>> That makes the resolution we made today absolutely wrong:
>> http://www.w3.org/2010/02/rdfa/meetings/2011-03-24#resolution_2
> 
> how?
> 
>> It also means that we have had a bug for SVGTiny1.2+RDFa 1.0 for quite
>> some time (but it really didn't affect anybody).
>> We need to fix this before 2nd Last Call because it could result in a
>> 3rd Last Call. We /could/ go into 2nd Last Call and say that we're not
>> going to address this issue, but it will inevitably lead to someone
>> asking why this:
>> <svg property="dc:title" content="The Image">...</svg>
>> doesn't result in a triple, but this does:
>> <svg><g property="dc:title" content="The Image">...</g></svg>
> 
> doesn't look like it to me! I can't say any way for that to produce a triple. for it to produce a triple then one of the following would need to be satisfied /after/ the root element has been processed:
> 
> - base != null
> - parent subject != null
> - parent object != null
> 
> and they are all null.
> 
> Best,
> 
> Nathan
> 
>> and why this results in a blank-node of type "foaf:Document":
>> <svg typeof="foaf:Document">...</svg>
>> The current approach to fix this is to assume about="" on the root
>> element of all RDFa documents. This works across HTML, XML, SVG and all
>> other document types. We already explored initializing 'new subject' to
>> 'base', and 'parent object' to 'base' - they're both problematic.
>> Shane's having a think on it.
>> Here's what we'll try to do tomorrow:
>> 1. PROPOSE and RESOLVE to fix the issue above, retracting the decision
>>   made today about XML+RDFa and about="" (which is clearly wrong).
>> 2. PROPOSE and RESOLVE to go into 2nd Last Call with the change made
>>   in #1.
>> We will be PROPOSE/RESOLVING via this mailing list, so it is vital that
>> as many RDFa WG members respond with their "+1/-1" as possible. So, keep
>> your eyes peeled for the proposals tomorrow and make sure to send in
>> your +1/-1 or we'll miss our narrow window for 2nd LC.
>> -- manu
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Attachments

Received on Friday, 25 March 2011 11:13:46 UTC