GSOC weekly report #2

04/06/2010

Hello Planet! Here’s my weekly GSOC report for Hormiga, the Tracker based ORM.

While last week was dedicated to coding the basic blocks of the ORM (ontology lexer and parser), this week I set up the first blocks of the ORM itself. What I did:

  1. Define the mapping format: it will be JSON based, and look like that: 
    {
    RdfClass: "nao:Tag",
    Name: "Tag",

    Properties: [
        {
            RdfName: "rdfs:label",
            Name: "label"
        }
    ]
}

    The good thing is that JSON makes it expansible (the parser will just ignore any unknown element), so that we can add missing bits later.

  2. I wrote a parser for this format
  3. I wrote an ontology parser (what I had was a turtle parser, producing statements but not “interpreting” them). It’s pretty basic ATM, only enumerating classes and properties.
  4. I wrote the first steps of the mapping, that is load the mapping file, check it, load the ontology files, check them, and check that the classes and properties used in the mapping are defined in the loaded ontologies.

I though I would be able to do a bit more, but I got more work that what I expected (blame my internship tutor who gave me a lot of interesting things to do). So far, I’m not late, but just on time.

What can we expect next week ? Well, more thorough checking of the mapping file, and the specification of how code generation will be done. I’m still not totally clear on how I’ll do that, but I’m pretty sure my mentor will have interesting ideas, since he’s the author of Vala.

Posted by Adrien Bustany
Filed in Technical things
Tags:
3 Comments »

3 Responses to “GSOC weekly report #2”

  1. Adrien Bustany: GSOC weekly report #2 | Gnu Architecture Says:

    05/06/2010 at 2:12 am

    […] Planet GNOME Related Posts:Jakub Steiner: Leaving NovellStormy Peters: Words are important – just not always the way you thinkHow To Take a Screenshot of your Droid with Ubuntu GNU/Linux […]

  2. John Carr Says:

    05/06/2010 at 6:20 am

    Wouldn’t it be useful to add this to tracker its self? I think metadata about metadata schemas is perfectly valid…

    Another thing to consider is reverse mapping: Quite often you find yourself wanting to traverse in the other direction. Hypothetical example would be that:

    Album hasSong Song

    But the ORM wants to add a getAlbum() property to the song. So you need metadata to handle that (in a lot of cases a reverse property would need an alternative name to make sense).

    • Adrien Bustany Says:

      05/06/2010 at 2:20 pm

      @John: Do you mean, adding mapping files for all classes supported by Tracker to Tracker itself? I’m not totally sure I’d do it that way, because the number of properties can grow huge (think of a very specific class with a large number of parents). Furthermore, we’d need to do inference to guess all the properties that can apply to a single class. I’m not discarding the idea, but so far I think it’s way easier to allow the user to pick the properties he needs, and not end with tons of generated code.

      About reverse properties, it’s something a bit tricky, I think a syntax like that would work (for a property object) :

      
{
    "RdfName": "hasSong",
    "ReverseName": "album",
    "Name": "song"
}

      The presence of the ReverseName key determines if a reverse property has to be built.


Comments are closed.