Naicong,

I ran into the same issue with my translator.   I had been using the  
file suffix in the baseURI (e.g., http://www.symbolics.com/ontosem.n3)and 
  namespace (e.g., http://www.symbolics.com/ontosem.n3#) of my source  
models, because I read somewhere that keeping the suffix is a "best  
practice."   I considered writing code to parse the ontology, import,  
and prefix statements and change them, but I was not sure how to  
correctly handle models outside my domain, then it occurred to me that  
a simpler solution would be to make the baseURI's and namespaces of my  
models to be storage language neutral (e.g., http://www.symbolics.com/ontosem) 
  and let the URI mapper take care of the mapping to physical model  
file, by using Composer's convention of embedding the baseURI as a  
comment in the file header.   I decided not to alter 3rd party  
imported models/import statements, leaving them the way the 3rd party  
defined them (mostly .owl).   It looks like most of the TBC models  
exclude the suffix from the baseURI/namespace.

Another option is if the baseURI/Namespace refactoring functionality  
in TopBraid is exposed in SparqlMotion, you could use that to directly  
refactor the namespaces and uri's, however the issue of 3rd party  
imported models remains.

I look forward to hearing the TBC team's suggestions on how best to  
handle 3rd party imports.

Arthur


On May 19, 2009, at 1:13 AM, Li, Naicong wrote:

> Hi Scott,
>
> It appears that when we do file format conversion using  
> sml:ImportRDFFromWorkspace and then sml:ExportToRDFFile, the output  
> model contains the actual triples from its imported models.  For  
> example, your Tutorial material US-state.owl imports region.owl.   
> When I converted US-state.owl to US-state.n3 (using the two modules  
> above), the resulting US-state.n3 actually contains the definition  
> for classes like Region, City, etc., which are defined in  
> region.owl) --  even though US-state.n3 still state that it imports  
> region.owl.  What do I need to do so that the output model does not  
> contain the triples in its imported model?
>
> Naicong
>
> From: [email protected] 
> [mailto:[email protected] 
> ] On Behalf Of Scott Henninger
> Sent: Wednesday, May 13, 2009 10:40 PM
> To: [email protected]
> Subject: [tbc-users] Re: File format conversion
>
> All;  Attached is a script that creates a list of files and the  
> names to convert to (see CreateFileList).  This iterates through the  
> list and saves each to the filename specified in the :newName  
> property.  Composer will save the file in the format specified  
> {.n3, .owl, .rdf, .nt}.  The same sort of things can be done in a  
> separate RDF file or spreadsheet, as Irene suggested.
>
> This script is also set up as a Web service, so you can call it  
> remotely via http://<host>/tbl/actions? 
> action=sparqlmotion&id=ImportExportFileList
>
> ...for TBC-ME, use "localhost:8083".  Using a Live server, specify  
> the host name that Live is running on.
>
> -- Scott
>
> Arthur Keen wrote:
> Naicong
>
> I asked about this a couple of months back and I was quite surprised  
> that Composer does not directly implement this capability.  I  
> thought Holger's solution would work well for one-time or infrequent  
> translation, but my challenge is that I have to keep the models in  
> n3 and owl in synch throughout development through lots of changes.   
> I estimated that it would  take a longer time to learn SPARQLMotion  
> than to simply code a solution in Java.    Creating a spreadsheet of  
> all my files would be tedious and error prone because I have many  
> models in a very deep file hierarchy and I would have to re-visit a  
> spreadsheet of all models often because of frequent re-factoring.   
> So, I wrote a small Java utility that recurses through a source  
> directory tree, creates an equivalent target directory tree, and on  
> encountering .n3 files, loads them, and then saves them in RDF/XML  
> into the equivalent location in the target directory structure.  Is  
> this what you are looking for?
>
> Arthur
>
> On May 13, 2009, at 7:59 PM, Li, Naicong wrote:
>
>
> Hi Irene,
>
> I checked the SPARQLMotion functions list and did not see any  
> obvious that I could use.  I check the old emails on this list and  
> found this one below.  Do you mean I need to do something like what  
> Holger is describing?
>
> Thanks for the help.
> Naicong
>
> ============================
> <image001.gif>
> Arthur
> View profile
>  More options Feb 19, 5:23 pm
> Is there an easy way in TopBraid to convert an entire project
> containing a large number of models in .N3 file format to another
> format e.g., .OWL?  The project contains about 50 models and the
> developers would feel more comfortable with xml trainer wheels.
>
>
> <image001.gif>
> Holger Knublauch
> View profile
>  More options Feb 19, 6:15 pm
> Not out of the box, only SPARQLMotion could help. You would need the
> list of file names though, somehow (e.g. from a spreadsheet). Then use
> a SM script to import that spreadsheet and iterate over all file
> names. Then use sml:ImportRDFFromWorkspace to load and the
> corresponding export module to save it back in the new format.
> Holger
>
>
>
> From: [email protected] 
> [mailto:[email protected] 
> ] On Behalf Of Irene Polikoff
> Sent: Tuesday, May 12, 2009 5:20 PM
> To: [email protected]
> Subject: [tbc-users] Re: File format conversion
>
> Yes, of course, with a SPARQLMotion script
>
> From: [email protected] 
> [mailto:[email protected] 
> ] On Behalf Of Li, Naicong
> Sent: Tuesday, May 12, 2009 7:58 PM
> To: [email protected]
> Subject: [tbc-users] File format conversion
>
> Hi,
>
> Because of our project needs, we need to convert the ontology format  
> between .n3 and .owl quite often (sometimes to .allegro as well).   
> We have about 40 ontologies, and in the past we did the conversion a  
> couple times by manually exporting each file to a different format  
> and it’s very time consuming (and error prone).   Is there a way  
> that we can do this in a batch?
>
> Thanks.
> Naicong
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TopBraid Composer Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/topbraid-composer-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to