Re: Some RDFa 1.1 Core edge cases that we need to clarify

On Oct 24, 2010, at 5:34 AM, Toby Inkster wrote:

EXAMPLE 1:

<html vocab="http://example.com/1#">
 <head>
   <base href="http://example.com/base" />
 </head>
 <body vocab="2#">
   <h1 property="title">Hello World</h1>
 </body>
</html>

What is the triple here? @vocab is supposed to be an absolute URI, but
here on <body> it's relative. So, should parsers error-correct and thus
create a triple with predicate <http://example.com/2#title>; should
they ignore that vocab attribute, and generate a triple with predicate
<http://example.com/1#title>; or should the invalid vocab value reset
the default vocabulary to undefined, meaning that the token "title"
can't be expanded to anything, thus no triple is generated?

My read of section 7.4 is that the body @vocab is ignored, so the one that remains in effect is that on the html element. This would result in <http://example.com/1#title>.

TERMorCURIEorAbsURI

 *   If the value is an NCName<http://www.w3.org/TR/2006/REC-xml-names-20060816/#NT-NCName>, then it is evaluated as a term according to General Use of Terms in Attributes<http://www.w3.org/2010/02/rdfa/drafts/2010/WD-rdfa-core-20101026/#s_terms>. Note that this step may mean that the value is to be ignored.
 *   If the value is a valid CURIE, then the resulting URI is used.
 *   If the value is an absolute URI, that value is used.
 *   Otherwise, the value is ignored.

EXAMPLE 2:

A profile defines:

[] rdfa:term "Agent" ; rdfa:uri foaf:Agent .
[] rdfa:term "agent" ; rdfa:uri event:agent .
[] rdfa:term "name" ; rdfa:uri foaf:name .


That's fine, and this should work:

<div about="#myevent" rel="agent">
 <span typeof="Agent" property="name">Toby Inkster</span>
</div>

But what happens here? It doesn't seem to be well-defined.

<div about="#myevent" rel="AGENT">
 <span typeof="AGENT" property="NAME">Toby Inkster</span>
</div>

Indeed, this is not well defined, and which of the terms it resolves to is indeterminate. If we were to choose a solution, I'd go for using a case-sensitive ordering to defined terms based on UTF-8 sort order. Trying to keep them in order of definition may be problematic when values are stored in a hash, where some languages do not define an entry order.

--
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Gregg

Received on Sunday, 24 October 2010 18:01:44 UTC