Re: Non-XHTML host languages for RDFa

Toby Inkster wrote:
> On Mon, 2009-11-30 at 10:45 +0100, Ivan Herman wrote:
>> Thanks Toby. These are important information if we work on non-HTML
>> RDFa in the next incarnation of the RDFa group...
>>
>> As a comment on your question on SVG 1.2:
>>
>> [[[
>> Should the predefined XHTML+RDFa keywords (e.g. "next", "prev") be
>> supported in SVG?
>> ]]]
>>
>> my answer is: I do not think so. And, actually... SVG1.2 Tiny is a
>> Recommendation, so I do not believe that question is relevant until
>> (and if...) the SVG group wants to update SVG1.2 Tiny. Ie, my feeling
>> is that, in the note, we should make it clear that keywords should not
>> be recognised in SVG...
> 
> I've done a little more digging into this question. The SVG Tiny 1.2 Rec
> says:
> 
>  RDFa enforces the further requirement that each value
>  string must be a CURIE
> 
> Essentially they say "we don't enforce any requirements on the tokens in
> this attribute, but RDFa needs them to be CURIEs". However, that's
> factually incorrect. There are essentially two questions which emerge:
> 
> 1. Is rel="next" OK to use in SVG. (I suspect the answer is yes.)
>

Well...

http://www.w3.org/TR/SVGMobile12/struct.html#RelAttribute

indeed refers to HTML4 and RDFa in their treatment of @rel/@rev. But
they do not seem to define a set of default keywords. My interpretation
is that there is no keywords in SVG's @rel, use 'real' CURIE-s.

> 2. What should an RDFa processor do with it? (This is unclear.)
> 
> I suspect that the definitive answer should come from the SVG group.
> 

That in any case.

However: if we work on a generic XML+RDFa, we essentially have two
possibilities:

1. we define some sort of a generic mechanism whereby an XML application
language (and maybe even the user!) can define his/her own set of
keywords. This should be compatible with what we have in XHTML+RDFa and
it is then up to the SVG group to decide whether they want to use it or not

2. we scrap the whole mechanism of keywords except for XHTML for
backward compatibility reasons.

I must admit I tempted to go for #2; the only reason we kept the keyword
mechanism in RDFa was for historical reasons only, and I do not see why
this mechanism would have any particular value for other XML dialects
where history is not a factor...

Ivan



>> I was surprised not to see reference to the same issue for DataRSS. I
>> must admit I never looked at that spec. Do they accept the xhtml
>> keywords?
> 
> DataRSS has pretty similar language over their definition of @rel,
> saying that it must contain CURIEs. However, unlike SVG Tiny 1.2, they
> include a normative reference to the XHTML+RDFa spec. So this seems to
> me to be a situation like:
> 
> 1. Is rel="next" OK to use in DataRSS. (No.)
> 
> 2. What should an RDFa processor do with it? (Process as per XHTML
> +RDFa.)
> 
> Another interesting question about DataRSS is, given the following
> (example from the "Understanding DataRSS" page of the SearchMonkey
> Guide):
> 
> <atom:entry>
>   <atom:id>http://the.url/in/question</atom:id>
>   ...
>   <y:adjunct version="1.0" name="com.yahoo.test">
>     <y:meta property="tagspace:tags">tag 1 tag2 tag3 tag4</meta>
>     <y:item rel="dc:subject" resource="http://photosite.com/img.jpg">
>       <y:type typeof="media:Photo">
>         <y:meta property="dc:creator">The Nameless One</meta>
>       </y:type>
>     </y:item>
>   </y:adjunct>
> </atom:entry>
> 
> What is the subject URI of the "tagspace:tags" triple? Should it be
> taken from the <atom:id> element?
> 
> In version 0.3x of RDF::RDFa::Parser I may well include special support
> for Atom, in which if an <atom:entry> element is encountered, a new
> subject URI is set to the address given in <atom:id>, or a new bnode if
> no <atom:id> child exists.
> 

-- 

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