Re: A possible design to incorporate collections and containers into RDFa? [ISSUE-16]

  Ivan et. al.

The core of your question to me seems to be "is a string like 
'::something' meaningful in RDFa 1.0?  If not, is there a way to use 
this pattern in RDFa 1.1 as a way of signaling special processing?"

As to the first question...  it depends.  There are multiple contexts in 
which strings might be evaluated in RDFa 1.0.  When looking at the 
datatype CURIEs (as used by @property), the string '::something' would 
be illegal and should map to ''.  This is because the leading ':' would 
match the production for a CURIE using the default prefix; however, the 
rest of the string *does not* match the production for an irelative-ref, 
and therefore MUST NOT be interpreted as a CURIE.  So, as I said, this 
would map to ''.

When looking at the datatype URIorSafeCURIE (as used by @resource), such 
a string would not be interpreted as a URI and is clearly not a 
SafeCURIE.  Therefore, in such a context that string MUST NOT be treated 
as a legitimate target in RDFa 1.0.

NOTE: This is according to the literal text of the spec and its 
referenced specifications.  It is certainly possible that 
*implementations* of RDFa 1.0 would do something different here.  We 
don't have any tests for this, and I have never thought about it before.

Now, the second question...  Is there a way to use this pattern in RDFa 
1.1?  I think my answer has to be 'maybe'.  Basically, since, as per my 
arguments above, this pattern does not match our productions for CURIE 
nor for URI, we can define it as a new pattern.  New productions.  New 
datatype.  We could also EXTEND the definition of CURIE in such a way 
that a CURIE prefixed with two colons has special meaning.  This has 
ramifications beyond RDFa though, and we would need to consider 
carefully before going that way.

I feel like strings like these are instructions to the processor.  In 
the past people have called things like this a 'pragma'.  Perhaps there 
is a way to define a 'pragma' datatype and then extend the datatypes of 
attributes that take such instructions to be 'pragma | 
whateverDataypeIsAlreadyThere'.

On 8/29/2010 3:25 AM, Ivan Herman wrote:
> On Aug 28, 2010, at 22:51 , Toby Inkster wrote:
>
>> On Wed, 25 Aug 2010 13:40:50 +0200
>> Ivan Herman<ivan@w3.org>  wrote:
>>
>>> I wrote down my current design on the Wiki:
>>>
>>> http://www.w3.org/2010/02/rdfa/wiki/ContainersAndCollections
>> I think this is a good start. Little problem though re the use of
>> @resource to trigger the list behaviour. Consider the following:
>>
>> 	<div about="#eachpeach">
>> 	<i property="dc:title">Each Peach Pear Plum</i>
>> 	<ul rel="dc:creator" resource="::Bag">
>> 	<li property="::member">Janet Ahlberg</li>
>> 	<li property="::member">Allen Ahlberg</li>
>> 	</ul>
>> 	</div>
>> 	<div about="#megmog">
>> 	<i property="dc:title">Meg and Mog</i>
>> 	<ul rel="dc:creator" resource="::Bag">
>> 	<li property="::member">Helen Nicoll</li>
>> 	<li property="::member">Jan Pienkowski</li>
>> 	</ul>
>> 	</div>
>>
>> If this were parsed in an RDFa 1.0 parser, it would come out as:
>>
>>   <#eachpeach>
>>     dc:title "Each Peach Pear Plum" ;
>>     dc:creator<./::Bag>  .
>>   <#megmog>
>>     dc:title "Meg and Mog" ;
>>     dc:creator<./::Bag>  .
>>   <./::Bag>
>>     <http://www.w3.org/1999/xhtml/vocab#:member>  "Janet Ahlberg" ;
>>     <http://www.w3.org/1999/xhtml/vocab#:member>  "Allen Ahlberg" ;
>>     <http://www.w3.org/1999/xhtml/vocab#:member>  "Helen Nicoll" ;
>>     <http://www.w3.org/1999/xhtml/vocab#:member>  "Jan Pienkowski" .
>>
>> Any automated agent looking at that would conclude that the two books
>> have the same authors. Something using, say, @typeof wouldn't suffer
>> from this problem.
>>
> I wonder, but I may be wrong. Is @resource="::Bag" legal? Didn't we say that for a relative URI to be really kosher one should do something like @resource="./XXX"? What I am trying to see if we can have the "trigger" strings ::Bag, ::member, etc, defined in such a way that they would be illegal if they stayed around on the RFDa level. I guess ::member is fine, because it cannot be interpreted as a term (it is not an NCNAME) and it is not an absolute URI. If we found the right strings that we would be safe. (I explicitly added Shane because he knows this better than everyone...)
>
> But if there is no such string we may indeed have a backward compatibility issue in any case. Ie, if what we put into the attributes (both for @typeof or for @resource) is interpretable in RDFa 1.0 we could get to such problems.
>
> An easy way out is to define a separate attribute for these, something like parse_type (to borrow from the terminology used by RDF/XML). Ie, we could say that:
>
> <span ... parse_type="Bag">
>
> would generate the whole thing either by reusing an existing @resource or adding a new one with a blank node. That might have the added value (though rarely used in practice) to have a non-blank node acting as the rdf:Seq or the list header. But I was just a bit weary of adding a new attribute, though that may be the way to go.
>
> As I said in my previous answer to Christoph[1] I feel there are too much problems reusing @typeof due to the additional and somewhat complex rules around it. I think it would scare away lots of users. Ie, I would prefer even accepting that corner case danger rather than creating a complex situation because of that corner case...
>
> Cheers
>
> Ivan
>
>
> [1] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Aug/0173.html
>
>> -- 
>> Toby A Inkster
>> <mailto:mail@tobyinkster.co.uk>
>> <http://tobyinkster.co.uk>
>>
>
> ----
> 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
>
>
>
>
>

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

Received on Sunday, 29 August 2010 14:59:11 UTC