The difficulty I see stems from lacking knowledge about how the vocabulary is structured. If I am looking for the Class for City I need to "navigate" trough "Er", and NOT "Em.E". Now there is no self contained explanation what these things mean. You need to kind of know what you're looking for (and in this case, whether OpenCalais provides additional metadata for such types which determines if it is "er" or "em/e").
Now in the Calais vocabulary the number of Classes/Properties is not too big so it may still be feasible to explore a bit to find the right thing. I wonder if this assumption can be generalized. On Tue, Oct 18, 2011 at 8:43 PM, Reto Bachmann-Gmür <m...@farewellutopia.com>wrote: > It seems the properties are reasonably grouped, so this would make it > easier to browse. When looking for a 'geo/village' I first > autocomplete 'geo' and then 'village', this gives me smaller choices > in the autocompletion menus. > > Reto > > On Tue, Oct 18, 2011 at 8:18 PM, Daniel Spicar > <daniel.spi...@trialox.org> wrote: > > I wonder what is easier to deal with when working with the vocabulary in > > code. > > > > With the inner class approach, code completion will not directly offer > the > > available classes/properties. It is more difficult to "browse" when > looking > > for a property/class. If looking for a specific property one needs to > know a > > bit about the vocabulary to find it quickly. > > > > In the other case one can list all the properties at once and "browse" > > trough them easily and one does not need to know the vocabulary well to > find > > a specific property. I just wonder if it will be difficult to keep an > > overview, especially as the constant names can get pretty long > potentially. > > > > On Tue, Oct 18, 2011 at 2:00 PM, Reto Bachmann-Gmür <r...@apache.org> > wrote: > > > >> What about creating a static inner class per path section? > >> > >> Cheers, > >> Reto > >> On Oct 18, 2011 9:46 AM, "Daniel Spicar" <daniel.spi...@trialox.org> > >> wrote: > >> > >> > Hi clerezza people, > >> > > >> > I ran into an issue with SchemaGen. I tried to create a Java class > >> > representing the Calais Ontology ( > >> > > >> > > >> > http://www.opencalais.com/files/OpenCalaisLinkedDataSchema_R4_Jan09.rdfs_.txt > >> > ). > >> > The problem is, that the Ontology uses paths instead of fragment > >> > identifiers > >> > to identify and classify different "types", "entities", etc. > >> > > >> > e.g.: > >> > http://s.opencalais.com/1/type/em/e/Anniversary > >> > http://s.opencalais.com/1/type/er/Company > >> > http://s.opencalais.com/1/type/er/Geo/City > >> > > >> > Now SchemaGen needs me to declare the Ontology like this: > >> > <owl:Ontology rdf:about="http://s.opencalais.com/1/"; /> > >> > > >> > But this won't work, because SchemaGen fails to generate java > constants > >> > from > >> > paths, e.g. it won't be able to create a constant from > >> > type/em/e/Anniversary. > >> > Therefore I need to declare the ontology for each different subpath > like > >> > this: > >> > <owl:Ontology rdf:about="http://s.opencalais.com/1/type/em/e/"; /> > >> > <owl:Ontology rdf:about="http://s.opencalais.com/1/type/er/"; /> > >> > <owl:Ontology rdf:about="http://s.opencalais.com/1/type/er/Geo/"; /> > >> > > >> > And I need to do this in 3 different files. > >> > > >> > This is pretty annoying. Is there any way to circumvent this? > >> > > >> > If not, what would be a clever way to avoid this problem? I assume the > >> > problem stems from SchemaGen trying to create Java Constants with > slashes > >> > in > >> > their names which I assume is illegal. We could do a simple solution > of > >> > using some other character in this case (e.g. "_"). But does anyone > have > >> an > >> > idea how to solve this issue in a nicer way? > >> > > >> > Daniel > >> > > >> > > >
