[Xesam] Desktop ontology svn layout

[Sebastian Trüg]

On Monday 29 June 2009 09:35:58 Sebastian Trüg wrote:
> On Monday 29 June 2009 02:32:45 Leo Sauermann wrote:
> > ok, so we agree.
> >
> > still - use N3 and do two files, trig sucks.
>
> due to missing tool support?
> Two files means having build tools that merge them. These cannot be based
> on java!

actually I think this is not correct. We could have the files generated on the 
server. Then I think it is OK to use java tools. However, if the files should 
be generated at build-time, then we should use scripts, python or perl or bash 
or whatever.

Is there someone with scripting skills here?
I am thinking about 3 input files:
1. the common namespaces which we use for all ontologies
2. the actual N3 source of the ontology itself
3. the metadata n3 file

I am working on that now.


> Thus, we would have to write them. As soon as those tools are in
> place I will happily change to N3. But for now I will stay with trig.
>
> Cheers,
> Sebastian
>
> > best
> > Leo<
> >
> > It was Sebastian Trüg who said at the right time 26.06.2009 19:54 the
> >
> > following words:
> > > On Friday 26 June 2009 18:08:52 Leo Sauermann wrote:
> > >> If possible, it would be good if you could look into the currenty ANT
> > >> scripts that do the whole business of generating the HTML files and
> > >> converting the ontologies.
> > >
> > > I will try. Never used ant before but I will manage. :)
> > >
> > >> The current layout is not because we like chaos, but because our
> > >> current set of ANT scripts works with that setup and it was too hard
> > >> to change the script (it was easier to just put all ontologies into
> > >> the same folder and then tweak the ant script)
> > >
> > > sure. I know how this works. Stuff grows.
> > >
> > >> In general, I do not like the smell of release/draft folders, but I
> > >> think its ok.
> > >> I think each ontology should be in its own folder and some readme.txt
> > >> should show the status, but its also fine the way with superfolders.
> > >> but
> > >
> > > I thought about that, too. But a folder structure seems cleaner to me.
> > > You can get all stable ones by simply checking out that folder. It is
> > > also simpler for release scripts, not to mention a human trying to
> > > understand the structure.
> > >
> > >> we should not try to classify them further using folder strucutres,
> > >> this will end up in sucking, rather use the wiki to guide people
> > >> around.
> > >>
> > >> The W3C way is something like
> > >> ...2009/06/ndo-draft  .... then
> > >> ...2006/08/ndo-draft  ... then
> > >> ...tr/ndo
> > >
> > > I doubt we need this. The year is not really interesting IMHO, it is in
> > > the svn metadata anyway.
> > >
> > >> we should use SVN tags to mark releases and otherwise keep the files
> > >> always in the same folder, its much more convenient, but also here I
> > >> am open for ideas.
> > >
> > > yes, svn tags for releases.
> > >
> > >> about TRIG: (I would like N3, see below)
> > >> this is fine, we stopped using protégé for ontology development some
> > >> time ago, because as we are doing a standardization process, the SVN
> > >> logs are very very very important to verify what chnages have been
> > >> done, and a visual ontology editor sometimes reformats the whole file,
> > >> which makes it impossible to verify what has been changed by whom and
> > >> why, so I am in favor for TRIG and text files.
> > >> Could someone write this down on our OntologyMaintenance page?
> > >>
> > >> there is only one problem - there is a lack of online tools [1] for
> > >> checking/validating/converting trig, this sucks. For the sake of
> > >> keeping a sane mind, and being quick while hacking,
> > >> I would propose to use N3 instead because there is more tool support
> > >> for it.
> > >>
> > >> [1]
> > >> http://rdfabout.com/demo/validator/index.xpd
> > >> http://www.mindswap.org/2002/rdfconvert/
> > >> -> these tools, which I daily use when cheking ontologies, do not
> > >> support trig.
> > >> Trig=bad
> > >> n3=good
> > >
> > > hm, but wouldn't that again mean to have two files: the data graph and
> > > the metadata graph? I also wanted to avoid that. The other possibility
> > > would be to auto-generate the metadata from the release date and maybe
> > > the last svn change, the svn commiters and a metadata file.
> > >
> > > Cheers,
> > > Sebastian
> > >
> > > _______________________________________________
> > > Xesam mailing list
> > > Xesam at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/xesam
>
> _______________________________________________
> Xesam mailing list
> Xesam at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xesam