[owl-s] wsdl2owl-s conversion question, owl:imports and owl-s version

[Michael Dänzer]

Hi

>>   
>>> 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 
>>> work.
>>>       
>> 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:
>>
>>     ont.addImport(ont.getKB().read(myURI));
>>   
> 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 
> imports:
> line 183: 
> aOntNode.addImport(theModel.getResource(aOnt.getURI().toString()));
> 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 
> interesting...)
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 
commit it.
> 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?

Cheers
Michael
>
> Thanks for your help,
> Oliver
>> Hope this helps
>> Michael
>>   
>>> Best regards,
>>> Oliver
>>>     
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> OWL-S mailing list
> OWL-S at lists.mindswap.org
> http://lists.mindswap.org/mailman/listinfo/owl-s
>