Re: Subclassing literals in RDFa API and JSON serialization

Just to note that similar functions exist in RDFLib (though a bit hidden) and I had to make an extensive use of it for some of my RDFLib based systems (eg, OWL RL reasoner). This is just to bear witness that such methods are very important in practice...

I wonder whether a core set converters for integers, floats, etc, should not be provided/required by default. 

Ivan


On Apr 5, 2010, at 22:54 , Benjamin Adrian wrote:

> Hi all,
> 
> I hope you all had a relaxed weekend and nice Easter. My children got so
> much chocolate that we are well provided until Christmas. :)
> 
> I tried to extend the RDFa DOM API a bit in order to
> transform RDFLiteral objects into Native Datatypes.
> 
> RDFLiteral gained a new method:
> 
> T castToType (in T type, in optional TypedLiteralConverter typeCast)
> raises (InvalidTypeCast);
> 
> TypedLiteralConverter is an interface with a callable method:
> 
> T castToType (in RDFLiteral literal) raises (InvalidTypeCast);
> 
> This should allow us to specify bridges between XSD types and JS Classes.
> Developers can also write their own cast functions in order to deal with
> e.g., their own types.
> 
> BTW: I also added asJSON methods to RDFTriple and RDFTripleList.
> But we now have to specify the used JSON format. Any suggestions?
> Is Mark's JSON serialization suitable for this?
> 
> Just have a look at:
>  http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/
> 
> Best regards,
> 
> Benjamin
> 
>> I'm a big fan of adding optional bits to specs. I'm an implementer, so I
> like optional bits because optional bits tend to be the bits where
> implementers can have some fun. So what I'm proposing is an optional
> bit.
>> 
>> Where the RDFa API would normally return an object of type RDFLiteral,
> it should be allowed to return an object of some other type that
> implements the RDFLiteral interface.
>> 
>> If we imagine an RDFa API implementation in a language that supports
> multiple inheritance, a literal with datatype xsd:dateTime might be
> returned as an object that's a subclass of RDFLiteral, and also a
> subclass of the programming language's native datetime object.
>> 
>> Or in a language which doesn't do multiple inheritance, it the same
> literal might be represented as a subclass of RDFLiteral with an extra
> attribute called "datetime" that contains a copy of the datetime in the
> programming language's native datetime object.
>> 
>> I can imagine implementations wanting to provide such subclasses for
> types xsd:dateTime (and other XSD date- and time-related datatypes),
> rdf:XMLLiteral and xsd:anyURI, though I'm not suggesting this option be
> restricted only to those - if an implementation wants to be able to do
> something special with xsd:unsignedByte, then why not let it?
>> 
>> --
>> Toby A Inkster
>> <mailto:mail@tobyinkster.co.uk>
>> <http://tobyinkster.co.uk>
>> 
>> 
>> 
> 
> 
> 
> -----------------------------------------
> This email was sent using SquirrelMail.
>   "Webmail for nuts!"
> http://squirrelmail.org/
> 
> 
> 
> 
> -----------------------------------------
> This email was sent using SquirrelMail.
>   "Webmail for nuts!"
> http://squirrelmail.org/
> 
> 


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