[owl-s] wsdl2owl-s conversion question, owl:imports and owl-s version
mdaenzer at gmx.net
Thu Feb 1 06:40:27 EST 2007
>>> I already managed to enable the default owl:imports (Profile, Grounding,
>>> Service, Process) in the generated definition.
>>> ( http://lists.mindswap.org/pipermail/owl-s/2006-January/000643.html )
>>> But the ontology, that I have used to define the used OWL types
>>> (WSDL2OWL-S Converter), is still missing in the generated imports
>>> section. To understand this, is it thought to add the ontologies, that
>>> contain the used concepts automatically? Modifying the WSDLTranslator by
>>> adding a wrapper for the addImport(OWLOntology ontology) method doesn't
>> Yes, I observed similar things as well. I could not find the problem on
>> the first glimpse, but I found a workaround, which solves the problem
>> for me. I explicitly read the ontology to import at the import time:
> Yes. It seems to be a bit complicated, so I am fine with your
> workaround. ;-)
> I just noticed the wild hacks in impl.jena.OWLWriterImpl to try handle
> line 183:
> The theOntology (OWLOntology) object is used to create an aOntNode
> (jena Ontology) object and to get the URIs of imported ontologies. The
> OWLWriterImpl itself writes the internal jena model, so the
> writeInternal method needs to build two OntModel instances to
> serialize the OWLModel data.Confusing. Would it be not easier to hold
> Imports direct in the internal OntModel of OWLOntology and write this?
> I hope I understand the model correctly.
I guess, this part of the API is a liitle, hm, let's say, confusing.
Unfortunately, the original developer of that part seems to be off the
list. On my side, time is rare to do something, but if you have a fix
for that, just send it to me or anybody else of the members at the
google site and we will integrate it.
>>> In addition to this I am searching a method to define the OWL-S version
>>> of the generated OWL-S definition.
>> Have a look at the translator interface in org.mindswap.owl.OWLOntology
>> and the implementation classes in impl.owls. If you know the version at
>> design time, you could change the superclass of
>> org.mindswap.owls.vocabulary.OWLS to the version you need.
> No, unfortunately I need the 2 possibilities (OWL-S 1.0 and 1.1) to
> write the OWL-S definitions during runtime. I have to reconstruct a
> set of OWL-S definitions on the basis of WSDL definitions and the
> additional knowledge about used concepts (mappings) and the original
> OWL-S version (rebuild the grounding part). In principle I need the
> Translator functionality (of the examples) for both OWL-S versions.
> Apropos, the Translator is also a good example, how imports are
> handled, but there are two little things, that bother me a bit: First,
> the imported ontologies, that are in the same namespace as the OWL-S
> definition are generated as relative links. Second, I don't know when
> the rdf:about attribute of <owl:Ontology rdf:about=""> of imports
> section is filled with the definition name (that's what the translator
> does as default). Where I can configure that? (not so important, but
Unfortunaelty I never used the translators, I only have 1.1 services.
So, I have to let these questions open.
Only for the relative links. What exactly you mean with "in the same
namespace as the OWL-S definition"? The xml base definition. If yes,
this should be okay in my eyes. But I don't know the exact
specifications. I intend this behaviour bases on the underlying Jena API.
>>> I am using a nightly build version of the owl-s api and the wsdl package
>>> >from the svn trunk.
>> Be aware that Mindswap SVN repository is not used any longer. Stick to
>> https://owl-s.googlecode.com/svn instead. (See
>> http://lists.mindswap.org/pipermail/owl-s/2006-August/000923.html). But,
>> use checkouts at your own risk. Changes (especially from me) are not
>> tested carefully :-(
> Hey, the head revision of the repository builds without errors. You
> are doing a great job! :-)
Thanks, I am blushing :-) The are no (obvious) errors, I only commit
when the code compiles smoothly. But I do not check whether my changes
affect the overall funcationality of the API. As soon it works for me I
> I know about the repository change, but anyhow, a quasi official build
> and offered jar file with a defined functionality, as the nightly
> build was, would be nice as long as no serious changes are made.
As far as I see the (old) nigthly build was neither quasi official nor
had a defined functionality. It was and is the ongoing development
branch on which things can be totally broken apart. We would need a more
sophisticated development process, if we would like to offer more stable
nightly build such as a special branch to work with and then merge with
the head when new features or bugfixes are more or less stable.
Nonetheless, a nightly build for convenience for those who want the take
the risk, would be nice. I have no idea if this is possible with Google
Code, Bijan or Ron, do you know more?
> Thanks for your help,
>> Hope this helps
>>> Best regards,
> OWL-S mailing list
> OWL-S at lists.mindswap.org
More information about the OWL-S