Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] Protege db schema conversion

Timothy Redmond tredmond at stanford.edu
Thu Dec 6 10:59:21 PST 2012


>
> 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, protege-discussion-request at lists.stanford.edu wrote:
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 03 Dec 2012 12:37:36 -0800
>> From: Timothy Redmond <tredmond at stanford.edu>
>> To: protege-discussion at lists.stanford.edu
>> Subject: Re: [protege-discussion] Protege db schema conversion
>> Message-ID: <50BD0D90.5030501 at stanford.edu>
>> 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
> protege-discussion at lists.stanford.edu
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: 
> http://protege.stanford.edu/doc/faq.html#01a.03



More information about the protege-discussion mailing list