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

Shane,

thanks. It looks like my instinct on choosing the string I chose was fine.

As for the second question: I think the right formulation is "is there a way to use this pattern in RDFa 1.1 as a way of signaling special pre-processing". Ie, I look at it a bit like a pragma like, e.g., the CPP instructions are for C. After all, what CPP does is to transform the incoming file into something that the C compiler can handle. In other words, the #.... strings have no bearing on the compiler. Conceptually, I look at these ::List type strings the same way: it transforms the source (or the DOM tree) into something that the RDFa processing can handle. In this sense, I am not sure we have to define a separate datatypes; we could just define this as a separate transformation (I believe Ben called these under the heading of hgrddl)

Ivan  



On Aug 29, 2010, at 16:58 , Shane McCarron wrote:

> 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
> 
> 


----
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