Re: new client

Dan Brickley wrote:

>* Brant Langer Gurganus <gurganbl@rose-hulman.edu> [2003-10-22 10:45-0500]
>  
>
>>Me and a group of students at Rose-Hulman Institute of Technology are 
>>planning to tackle an Annotea client to be written in Java using J2ME.  
>>If anybody has any suggestions, we would appreciate them.
>>    
>>
>One goal I expect we share is finding an RDF parser that runs in a
>J2ME/MIDP environment. Most Java RDF parsers themselves use a separate
>XML parser, so I'm currently stuck at the subgoal of finding a SAX2 Java
>parser that works in MIDP. My best bet re RDF parser is the Rio parser
>shipping with Sesame, although Jena's ARP may be a possibility too.
>  
>
Yes, finding an RDF parser is good.  So far Jena is the one I've found.  
I'll look at Sesame.  Outside of Mozilla Help, I don't have development 
experience with RDF and networking and that stuff is already done in 
Mozilla.

>I'm curious why you've chosen J2ME rather than generic Java (J2SE I
>guess). Do you have mobile, geo-coding etc apps in mind? An interesting
>research / scoping question is to find out where the utility of
>Annotea-style Annotations end, and other RDF approaches should be used
>instead. For example, considering Restaurant reviews, you could use
>Annotea vocab to annotate the homepage of a restaurant. Or you could use 
>plain RDF/XML to just describe the restaurant itself. See 
>http://esw.w3.org/topic/RestaurantRecommendation for more notes and
>datasources on this front, if it's an app area that fits your goals. Or 
>http://esw.w3.org/topic/RestaurantsVersusTheirReviews for more notes on 
>modeling styles, 'doc centric' vs 'world centric' (Annotea being largely
>the former I think).
>  
>
The primary reason for trying this in J2ME is that our instructor wants 
that as a "should" level goal.  We can use J2SE, but it has to be pretty 
unique.  That is, not just a networked Tic-tac-toe game.  The reason we 
chose trying to make an Annotea client was that it might be something 
someone might want to do on the go, involved networking (a requirement), 
was not a game (a strong suggestion), hadn't been done before (in our 
brief research), had open source implementations for ideas, and was 
widely interactive.  Additionally, it had a server system already 
created which removes that burden.

-- 
Brant Langer Gurganus
CM 2275, x8613
Freshman, Rose-Hulman Institute of Technology

Received on Friday, 24 October 2003 00:20:48 UTC