Re: Protege db schema conversion

I don't know if this is good news or bad news but when I converted the 
clips file to the database format I had no problems.  I made a mysql 
dump, reloaded it and that was fine also.   Later - when I have a faster 
connection - I will give a link to the sql dump file.

Did you notice the problem right after doing the conversion to database 
format or did it only occur after making a sql dump and reloading it?  I 
am trying to figure out what is different about how I did things and how 
you did things.

-Timothy


On 12/07/2012 10:49 AM, Todd Detwiler wrote:
> Timothy,
> Thank you very much for the info. Yes this is helpful. I hadn't 
> noticed that all of the is_template values were set to true. Now the 
> question is, is this happening when converting the clips project into 
> a db project. If you have any time to look at my clips files, I have 
> posted them here: 
> http://dl.dropbox.com/u/2527438/FMA3.3/fma_3.3_frames_clips.zip. I 
> must warn you, however, that they require a large heap to open in this 
> format (I generally use 1.5G) and it takes a bit of time to open.
>
> Even if you don't have time to investigate, I appreciate your effort 
> and feedback so far. Unfortunately it still means that I have a 
> migration path problem.
>
> Thanks,
> Todd
>
> Landon Todd Detwiler
> Structural Informatics Group (SIG)
> University of Washington
>
> phone: 206-616-2336
>
> On 12/6/12 12:03 PM, [email protected] wrote:
>> Message: 1
>> Date: Thu, 06 Dec 2012 10:59:21 -0800
>> From: Timothy Redmond<[email protected]>
>> To:[email protected]
>> Subject: Re: [protege-discussion] Protege db schema conversion
>> Message-ID:<[email protected]>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>
>>> >
>>> >Yes, I have loaded the clips project (in multiple Protege versions)
>>> >and attempted to "Convert project to format" frames database. But it
>>> >does not look the same in Protege (as the clips version). None of the
>>> >classes have any info in the right frame (as though they were
>>> >un-typed). Also, many leaf concepts don't appear at all (in the tree).
>>> >I can query the database and find the missing classes. And, they have
>>> >valid types. I am using MySQL for my database backend. In fact, I am
>>> >using the same instance of MySQL that the initial db was in (before
>>> >upconverting the schema). I can send you the file, but it is too large
>>> >for email, even when compressed. So I've uploaded it here:
>>> >http://dl.dropbox.com/u/2527438/FMA3.3/fma_3_3.sql.zip 
>> Ok - I am a bit confused but there may be a hint here.  The database
>> dump that you sent me is bad.  The problem that it has is that all of
>> the is_template values in the database are set to 'true'.  You can see
>> this in the sql dump because one of the typical entries looks like this:
>>
>>        (':THING',6,':DIRECT-SUBCLASSES','','^A',0,do 6,'Anatomical 
>> entity',NULL)
>>
>>
>> where the ^A represents the binary character control-A (I think that
>> this is a 1 in ascii).  You can see this in the database by running an
>> sql query:
>>
>> mysql> select * from fma where is_template=false;
>> Empty set (0.00 sec)
>> mysql>
>>
>> This is why when I load this database and read it into Protege, I don't
>> see any subclass relationships.  Protege looks for :DIRECT-SUBCLASSES
>> with a isTemplate value of false and the database only has entries with
>> an isTemplate value of true.
>>
>> Now this is where I become uncertain.  Interestingly the symptoms that I
>> described are similar to some of the symptoms that you described (e.g.,
>> the subclass relationships are in the database in some sense but don't
>> appear in Protege).  The problem with the database dump is clear enough
>> but it is not clear when in the process it got corrupted.
>>
>> It seems like I have found a problem but not the problem that you
>> originally described.  I think that you indicated that you had a valid
>> clips file that lost data when converted to a database project. If I am
>> going to replicate this, it would seem that maybe I need to start with
>> the clips file.
>>
>> What is the next step?  Does the new information help?
>>
>> -Timothy
>>
>>
>>
>> On 12/03/2012 03:04 PM, Todd Detwiler wrote:
>>> >Please see my answers to follow-up questions below.
>>> >Thanks,
>>> >Todd
>>> >
>>> >Landon Todd Detwiler
>>> >Structural Informatics Group (SIG)
>>> >University of Washington
>>> >
>>> >phone: 206-616-2336
>>> >
>>> >On 12/3/12 2:22 PM,[email protected]  
>>> wrote:
>>>> >>---------------------------------------------------------------------- 
>>>>
>>>> >>
>>>> >>Message: 1
>>>> >>Date: Mon, 03 Dec 2012 12:37:36 -0800
>>>> >>From: Timothy Redmond<[email protected]>
>>>> >>To:[email protected]
>>>> >>Subject: Re: [protege-discussion] Protege db schema conversion
>>>> >>Message-ID:<[email protected]>
>>>> >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>> >>
>>>> >>
>>>> >>My first reaction was that I am not sure what is wrong but perhaps
>>>> >>getting some clarification on parts of the message will help me 
>>>> figure
>>>> >>out what is wrong.
>>>> >>
>>>> >>On 11/28/12 3:17 PM, Todd Detwiler wrote:
>>>>> >>>Through the life of Protege as a tool, the database schema has
>>>>> >>>undergone a few changes. As far as I know, the best approach for
>>>>> >>>upconverting the schema of a database ontology has always been to
>>>>> >>>first export it to clips (in an older Protege version) and then 
>>>>> open
>>>>> >>>that clips file in a newer Protege version and then save it out 
>>>>> to a
>>>>> >>>db. This has worked for us reasonably well in the past (we have an
>>>>> >>>ontology for which the developers still use an old Protege 
>>>>> version).
>>>>> >>>But lately this isn't working well any more. I can still 
>>>>> successfully
>>>>> >>>write out our ontology to clips files. Newer versions of 
>>>>> Protege (i.e.
>>>>> >>>3.4.7, 3.4.8, and 3.5beta) can open the clips file and things 
>>>>> look OK.
>>>> >>This makes it sound like you have successfully converted the 
>>>> database
>>>> >>project to a clips project.  I am also assuming from this 
>>>> description
>>>> >>that you are using Protege frames and not Protege OWL.
>>> >
>>> >It appears so. I have converted the project to clips and,
>>> >superficially, it looks fine in Protege. This is a fairly large
>>> >ontology (the FMA) at 80,000+classes and over 2 million relationships.
>>> >So, it does take a while to convert to clips and a rather large heap.
>>> >Oh, and yes it is in frames.
>>> >
>>>> >>
>>>>> >>>But when I try and save it out to a db, things go wrong. The 
>>>>> resultant
>>>>> >>>db, in the Protege UI, looks like all of our classes are untyped
>>>>> >>>(nothing in the right hand pane).
>>>> >>It sounds like you have taken a valid clips backed Protege frames
>>>> >>project, converted it to a Protege Database project (not a OWL/RDF
>>>> >>Database) project.  After doing the conversion, it sounds like the
>>>> >>database project does not look the same as the clips backed 
>>>> project.  If
>>>> >>so, it sounds like this is where the problem occurred. Did you 
>>>> use one
>>>> >>of the supported datablases (mysql or postgres)?  Is it possible 
>>>> to send
>>>> >>us the ontology so that we can try it out?
>>> >
>>> >Yes, I have loaded the clips project (in multiple Protege versions)
>>> >and attempted to "Convert project to format" frames database. But it
>>> >does not look the same in Protege (as the clips version). None of the
>>> >classes have any info in the right frame (as though they were
>>> >un-typed). Also, many leaf concepts don't appear at all (in the tree).
>>> >I can query the database and find the missing classes. And, they have
>>> >valid types. I am using MySQL for my database backend. In fact, I am
>>> >using the same instance of MySQL that the initial db was in (before
>>> >upconverting the schema). I can send you the file, but it is too large
>>> >for email, even when compressed. So I've uploaded it here:
>>> >http://dl.dropbox.com/u/2527438/FMA3.3/fma_3_3.sql.zip
>>>> >>
>>>>> >>>Also, lots of leaf classes appear to be missing in the tree. 
>>>>> Now, if I
>>>>> >>>query the database, these classes exist and have types.
>>>> >>Are you talking about sql queries here?
>>> >
>>> >Yes, SQL queries.
>>> >
>>>> >>
>>>>> >>>Further, if I open the new database ontology in Protege 
>>>>> 3.4beta, it
>>>>> >>>looks fine.
>>>> >>So the new database project looks fine in one version of Protege
>>>> >>(3.4.*?) but not in another one (3.5?)?  I believe that the database
>>>> >>backend format should be identical between the later 3.4 versions 
>>>> and
>>>> >>the 3.5 version.
>>> >
>>> >That is correct. It does not look fine in 3.4.7, 3.4.8, or 3.5beta.
>>> >But it does display fine in 3.4beta.
>>> >
>>> >Thank you for any help you can offer,
>>> >Todd
>>> >
>>>> >>
>>>> >>-Timothy
>>>> >>
>>>>> >>>What changes have occurred in the database backend, since 3.4beta,
>>>>> >>>that could be causing this?
>>>>> >>>Thanks,
>>>>> >>>Todd
>>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>> >
>>> >_______________________________________________
>>> >protege-discussion mailing list
>>> >[email protected]
>>> >https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>> >
>>> >Instructions for unsubscribing:
>>> >http://protege.stanford.edu/doc/faq.html#01a.03
>
> _______________________________________________
> protege-discussion mailing list
> [email protected]
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: 
> http://protege.stanford.edu/doc/faq.html#01a.03

_______________________________________________
protege-discussion mailing list
[email protected]
https://mailman.stanford.edu/mailman/listinfo/protege-discussion

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03