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 > > > [email protected] > > > http://lists.freedesktop.org/mailman/listinfo/xesam > > _______________________________________________ > Xesam mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xesam _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
