Re: New Issue: Allowing extension of RDFa Core

Toby Inkster wrote:

 

>
> I think it does make sense. It would allow, say, HTML+RDFa to allow
> @data to set a subject URI like @src does. (@data of course being an
> attribute on the <object> element.) Or HTML+RDFa to treat @datetime to
> provide a literal object on <time> elements.
>   

So, in these examples, you would declare that an attribute ISA subject, 
ISA object, or ISA predicate.  And also declare how the values are 
interpreted (by datatype I expect).  This seems like it might work as 
long as we limit the datatypes that we actually need to interpret to the 
datatypes in RDFa Core and maybe literal and XMLLiteral?
> However, unless the hooks are very convoluted, I don't think they would
> solve the @role use case. @role would probably want the subject and
> object of the triple to be calculated differently. For example:
>
>  <div role="main" id="foo">...</div>
>
> Ought to generate a triple along the lines of:
>
>  <> xhv:main <#foo> .
>
> i.e. forcing the subject to be the document's base URI regardless of the
> current RDFa subject (e.g. @about on a parent element), and using @id to
> set the object resource, even though @id is entirely ignored by current
> processing rules.
>
> A host language that included RDFa and the Role Attribute Module (e.g.
> XHTML 1.2) would probably want to specify a method for extracting @role
> triples separately from RDFa.
>   

Hmm...  I actually think that the right triples for @role are very 
different. 

         <#foo> xhv:role roleValueURI

In other words, subject has a role of whatever.  But still, that is more 
convoluted than a simple example like @data above.  You would need to 
say that a triple for @role has a subject of @id (or the xpath to the 
current node if there is no @id), that the predicate is the special 
XHTML Vocabulary term role, and that the object is the value of @role 
interpreted as (TERM | URIorCURIE)+ .  Yeah, that would be hard to 
incorporate into a general model.  On the other hand, if it is not in 
the general model, then how do we get RDFa Conforming Processors to deal 
with it?

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