Re: RDFa Core 1.1 XML+RDFa spec bug?

This was probably discussed on the call, but I just wanted to go through my understanding of the processing sequence and how it corresponds with what I think is the desired behavior for non-HTML host languages:

On Mar 24, 2011, at 7:39 AM, Shane McCarron wrote:

I disagree - we say this EXPLICITLY already.  For all contexts.  Section 7.5 starts with the following:


At the beginning of processing, an initial evaluation context is created, as follows:

 *   the base<http://www.w3.org/2010/02/rdfa/sources/rdfa-core/T-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<http://www.w3.org/2010/02/rdfa/sources/rdfa-core/T-parent-subject> is set to the base<http://www.w3.org/2010/02/rdfa/sources/rdfa-core/T-base> value;
 *   the parent object<http://www.w3.org/2010/02/rdfa/sources/rdfa-core/T-parent-object> is set to null;
 *   the list of incomplete triples<http://www.w3.org/2010/02/rdfa/sources/rdfa-core/T-list-of-incomplete-triples> is empty;
 *   the language<http://www.w3.org/2010/02/rdfa/sources/rdfa-core/T-language> is set to null.
 *   the list of URI mappings<http://www.w3.org/2010/02/rdfa/sources/rdfa-core/T-list-of-URI-mappings> is empty (or a list defined in the Host Language-defined default RDFa Profile).
 *   the term mappings<http://www.w3.org/2010/02/rdfa/sources/rdfa-core/T-term-mappings> is set to null (or a list defined in the Host Language-defined default RDFa Profile).
 *   the default vocabulary<http://www.w3.org/2010/02/rdfa/sources/rdfa-core/T-default-vocabulary> is set to null (or a URI defined in the Host Language-defined default RDFa Profile).

Yes, this is correct, however in Step 6 & 7:
[[[
• new subject is set to the URI obtained from the first match from the following rules:
• by using the URI from @about, if present, obtained according to the section on CURIE and URI Processing;
• otherwise, by using the URI from @src, if present, obtained according to the section on CURIE and URI Processing.
• otherwise, by using the URI from @resource, if present, obtained according to the section on CURIE and URI Processing;
• otherwise, by using the URI from @href, if present, obtained according to the section on CURIE and URI Processing.
If no URI is provided by a resource attribute, then the first match from the following rules will apply:
• if @typeof is present, then new subject is set to be a newly created bnode.
• 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';
]]]

So, for the root node, and any child nodes not having an explicit resource, new subject is set to parent object, not parent subject, which means that the document URI (or base, however derived), is not used as the new subject.

I believe that the solution is to create a rule for the root element of a document similar to that from XHTML+RDFa (which could now be redundant):

• 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 root element of the document. If it is, then act as if there is an empty @about present, and process it according to the rule for@about.

I suggest doing this, rather than initializing parent object, so that a document such as the following, would make sense:

<html typeof=foaf:Document></html>

I think this should generate <> a foaf:Document, instead of [a foaf:Document], which it would do otherwise.

The implication of this, is that a document such as the following (TC 0201) would produce triples:

<?xml version="1.0" encoding="UTF-8"?>
<svg      width="12cm" height="4cm" viewBox="0 0 1200 400"
     xmlns:dc="http://purl.org/dc/terms/"
     xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny">
  <desc property="dc:description">A yellow rectangle with sharp corners.</desc>
  <!-- Show outline of canvas using 'rect' element -->
  <rect x="1" y="1" width="1198" height="398"
        fill="none" stroke="blue" stroke-width="2"/>
  <rect x="400" y="100" width="400" height="200"
        fill="yellow" stroke="navy" stroke-width="10"  />
</svg>

Furthermore, I suggest that an RDFa 1.0 document (SVGtiny) which generate triples are actually in error. If there's language specific to SVGtiny with RDFa 1.0, I wasn't able to find it; if it generates triples now, I don't understand how.

Gregg

     Note that the parent subject is set to the base value.  What am I missing here?


On 3/24/2011 8:00 AM, Manu Sporny wrote:

We have a last-minute RDFa Core 1.1 spec bug. Thanks to Gregg Kellogg
for drawing our attention to it.

For the XML+RDFa tests - there is nothing that establishes a new subject
when the document starts to be processed.

That is 'base' is set to the document URL, but the processing rules are
written such that this markup wouldn't generate a triple:

<root>
  <foo property="dc:title">Test</foo>
</root>

but this /would/ generate a triple:

<root>
  <blah>
    <foo property="dc:title">Test</foo>
  </blah>
</root>

I think we would all like to see the markup above generate a triple, but
the processing rules do not allow that to happen. This works for
XHTML+RDFa because a 'new subject' is specifically set for <head> and
<body>.

I have a vague recollection that we did this because we wanted to make
sure authors in non-XHTML languages would want to generate triples and
would thus have to be explicit about specifying a subject. That seems
like an archaic rule now - perhaps we should just say that, in XML+RDFa,
the initial evaluation context initializes 'new subject' to 'base'. Or
we can use the same language that we use in the XHTML+RDFa document.

-- manu




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

Received on Thursday, 24 March 2011 23:07:41 UTC