tkurz / sesame-vocab-builder Goto Github PK

In VocabularyBuilderMojo class, outputDirectory, bundleOutputDirectory and remoteCacheDir cannot be changed because the Parameter is readonly = true.
Is it intentional...?
In that way I cannot customize the output of the generated classes..

I think the new features justify a new release:

• #12: L10N ResourceBundles
• #17: Casing of Constant names

I experimented using this tool to add the SPARQL 1.1 Service Description vocabulary to the core Sesame Model jar but needed to hand edit to change the case to upper-case to match the other vocabularies, and also needed to modify some URIs to disambiguate between bad ontology designing where URIs only differ by case.

https://bitbucket.org/openrdf/sesame/pull-request/270/ses-1880-add-sparql-11-service-description

The second issue is perhaps unavoidable in general, but we could work on it in future to allow a fully automated pipeline for these ontologies.

Initially I want to work on allowing the output of upper-case URI constants before working on disambiguating case-insensitive URI conflicts.

Part of the case of issue #8 may be that users are specifying different languages for the same predicate using different literals.

It may be useful to allow users to specify their preferred language and select from multiple labels, that appear with the same predicate, based on the language.

M2E integration was working, but it seems to have broken recently.
#16 or 0d8d1a4 are the likely candidates. Will work through it further, but probably want to delay the 1.3 release until it is fixed or I can figure out why it broke for me.

I think its time for a new release: 1.3

1.2.1 could also work for the bugfixes (#25, #27), but I'd prefer 1.3 since we also have a feature (#28 RDFa support)

OWLAPI-4 contains Rio wrappers for the OWLAPI parser implementations for Manchester, Functional, and OWL/XML. Supporting these as syntaxes for sesame-vocab-builder will be as simple as adding a dependency on owlapi-rio when version 4 is released.

The Mime-types and file extensions that will be supported are defined here:

https://github.com/owlcs/owlapi/blob/version4/rio/src/main/java/org/semanticweb/owlapi/rio/OWLAPIRDFFormat.java#L56

[INFO] Generating PODDSCIENCE vocabulary
[DEBUG] Loading input file
[DEBUG] XMLReader initialized using JAXP: com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser@532721fd
[DEBUG] Setting default preferred language: en
[DEBUG] Setting default package: com.github.podd.ontologies
[DEBUG] Setting default constant case: UPPER_UNDERSCORE
[DEBUG] completing default Bundle with preferred language en
[DEBUG] copying H_A_S__E_X_P_E_R_I_M_E_N_T_LABEL from en to default Bundle

The line above seems to indicate that the key is not null, so the value must somehow have been null.

Caused by: org.apache.maven.plugin.PluginExecutionException: Execution generate-vocabulary-resource-bundles of goal com.github.tkurz.sesame:vocab-builder-maven-plugin:1.3-SNAPSHOT:generate-bundles failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:459)
at java.util.Properties.setProperty(Properties.java:166)
at com.github.tkurz.sesame.vocab.VocabBuilder.generateResourceBundle(VocabBuilder.java:331)
at com.github.tkurz.sesame.vocab.plugin.ResourceBundleMojo.executeBuilder(ResourceBundleMojo.java:43)
at com.github.tkurz.sesame.vocab.plugin.AbstractVocabularyBuilderMojo.execute(AbstractVocabularyBuilderMojo.java:220)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more

Hey guys
I will commit our cool tool to http://iswc2014.semdev.org/.
@ja-fra @ansell : I add you as co-authors, if you do not want to be mentioned just ping me, otherwise I see this as a commitment ;)

The cleaning process for the localnames is done too early, resulting in corruption of the localname that is constructed. Ie, if the URI starts as http://example.org/property-2 it may end up being http://example.org/property_2

Fix is to run cleanKey later so a reference to the original key is available.

Pull request coming to fix it.

Need to be able to specify prefix in the maven configuration to match the CLI and programmatic behaviour.

The fix for this is in Pull Request #22

Error occurs when importing www.w3.org/2009/08/skos-reference/skos.rdf:

org.openrdf.model.util.GraphUtilException: Multiple http://www.w3.org/2000/01/rdf-schema#comment properties found
at org.openrdf.model.util.GraphUtil.getOptionalObject(GraphUtil.java:376)
at org.openrdf.model.util.GraphUtil.getOptionalObjectLiteral(GraphUtil.java:445)
at com.github.tkurz.sesame.vocab.VocabBuilder.getFirstExistingObjectLiteral(VocabBuilder.java:204)
at com.github.tkurz.sesame.vocab.VocabBuilder.run(VocabBuilder.java:158)
at com.github.tkurz.sesame.vocab.Main.main(Main.java:65)

It would be really useful to have JSON-LD contexts generated in a similar way to the localisation resource bundles.

Putting this here as an improvement to keep track of it.

Thanks for adding the maven plugin.

The addition of a new source folder by a maven plugin confuses (or is just ignored by) M2E unless there are a few small additions to the plugin. Some guidelines for enabling this can be found at:

http://wiki.eclipse.org/M2E/Extension_Development#m2e.2Fantlr3_code_generation_support_explained

Currently, maven plugin generates the ResourceBundles together with the source code.

This should be moved to the correct maven phase: generate-resources

The error may be is thrown because of /tmp im mac os is a symlink. Therefore, the parent (which should be created when it is not existent) is a file, not a directory.

The split of the mojo so that the resource bundles and the java code generation run in different phases was a good idea, as it matches the maven lifecycle.

Before merging a pull request to split the mojo up again it would be useful to verify that it still functions with both command line maven and M2E, as the previous approach worked with command line maven but the use of the builder changed in a way that broke M2E.

If I issue e.g. ./sesame-vocab-builder http://rdfs.org/sioc/ns.rdf SIOC.java -b, I got the following exception:

Exception in thread "main" java.lang.NullPointerException
    at com.github.tkurz.sesame.vocab.VocabBuilder.generateResourceBundle(VocabBuilder.java:239)
    at com.github.tkurz.sesame.vocab.Main.main(Main.java:130)

At the moment the prefixname is generated from input file, if it is not explicitly set. This is IMHO wrong, because the filename is not necessarily related to the prefixname. Especially for remote ontologies that are stored in temporary files with a random filename this approach creates wrong prefixnames. It makes more sense to guess the prefixname from the classname.

Using http://xmlns.com/foaf/spec/index.rdf throws a parser excepiton (line1,char1). @ansell Does Sesame has problems with leading comments (the foaf file starts with comment).

it happens with void, which generates code that does not compile

It should be fairly simple to integrate this into a maven plugin to automatically generate the vocab files from ontology sources on the fly in the style of the Antlr and Clerezza Ontology plugins:

https://github.com/antlr/antlr4/blob/master/antlr4-maven-plugin/src/main/java/org/antlr/mojo/antlr4/Antlr4Mojo.java

https://github.com/apache/clerezza/blob/master/maven-ontologies-plugin/src/main/java/org/apache/clerezza/ontologiesplugin/OntologyJavaClassCreatorMojo.java

Release Version 1.1 on Sonatype

For multi-lingual ontologies, the user may want the javadoc in one language (or offer all languages in the javadoc?). They may also want the runtime ability to display the most appropriate label to the current user based on their Locale.

When parsing the ontology, we have access to each of the languages, and we could provide these as ResourceBundle classes or .properties files.

There may be a larger effort needed to enable this. We would need to create a new framework for getting labels based on URIs. One way to do this may be to extend org.openrdf.model.Namespace with Namespace.getLabel(URI) to use the current Locale and Namespace.getLabel(URI, Locale) methods to use the default locale. I will propose this for Sesame for 2.8 if it is the easiest way to go, and then regenerate all of the Sesame vocabularies so that they also support it.

Btw, this should not block the release unless it turns out that it is very trivial.

Currently the builder produces wrong java, id an ontology contains reserved words as names for properties (or classes). This should be checked and prented. My idea is to prefix the reserved word with _ (e.g. _static, -default).