Source Control Mightmare

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Source Control Mightmare

nhoj_p
Greetings,

I've searched the message archives but have been unable to find
similar problems. I've been using Protege for the last 6 months and
have slow started to have more and more issues with how Protege saves
owl files.

The project I'm on is maintained in a perforce repository and branched
as required, once a branch is finished or stable it is merged back
into the main branch. The issue comes when you try to merge owl files.
A merge is takes about 3 days, of which over 2.5 days is just sorting
out manually merging the owl files. Identifying changes which have
occurred in both branches and then implementing those changes.

Is there a way of getting Protege to group and sort
objects/properties/attributes when it saves and owl file. I don't mind
how its ordered or grouped I'd just like some conformity to how it
does it.

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Source Control Mightmare

samsontu

Have you tried to do the version comparison and merging using the Prompt
plugin that comes with Protege? That's what the plugin is designed to do.

Samson

John Patrick wrote:

> Greetings,
>
> I've searched the message archives but have been unable to find
> similar problems. I've been using Protege for the last 6 months and
> have slow started to have more and more issues with how Protege saves
> owl files.
>
> The project I'm on is maintained in a perforce repository and branched
> as required, once a branch is finished or stable it is merged back
> into the main branch. The issue comes when you try to merge owl files.
> A merge is takes about 3 days, of which over 2.5 days is just sorting
> out manually merging the owl files. Identifying changes which have
> occurred in both branches and then implementing those changes.
>
> Is there a way of getting Protege to group and sort
> objects/properties/attributes when it saves and owl file. I don't mind
> how its ordered or grouped I'd just like some conformity to how it
> does it.
>
> John Patrick
> _______________________________________________
> protege-discussion mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
>


--
Samson Tu                    email: [hidden email]
Senior Research Scientist    web: www.stanford.edu/~swt/
Stanford Medical Informatics phone: 1-650-725-3391
Stanford University          fax: 1-650-725-7944

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Source Control Mightmare

Thomas Russ

On Jan 30, 2007, at 9:45 AM, Samson Tu wrote:

>
> Have you tried to do the version comparison and merging using the  
> Prompt
> plugin that comes with Protege? That's what the plugin is designed  
> to do.

That certainly helps with the merging step, but it doesn't solve
the problem of a real impedance mismatch between the somewhat
random order terms are saved by Protege and the assumption of
small, incremental and local changes that is made by source control
systems like CVS or SVN.

Defining a canonical order in which to save information would
greatly aid in using such source control tools with Protege
ontologies.  This would be a big help for large projects, so
I need to express my support for John's feature request.

It wouldn't really be all that hard to do, either.  All that
is required is to decide on the order to save (i.e., Classes
or Properties/Slots first) and then sort the objects by their
name before saving.  I have done this for an export plugin I
wrote and it isn't all that difficult.  An additional sort
on template slot information for classes will also cause the
substructure to be sorted.

That would at least cause the terms to appear in the same
order when there are no changes and that would go a long
way to making the resulting files work well with source
control tools.

If there is concern about the cost of sorting the objects
each time one saves, then this could be addressed by introducing
a configuration property that determines if one wants sorted
output or not.  My feeling is that sorting doesn't add much
overhead on saving, but I haven't used this on very large
ontologies.

But I think this would be a good feature to include in the
next version of Protege.


>
> John Patrick wrote:
>> Greetings,
>>
>> I've searched the message archives but have been unable to find
>> similar problems. I've been using Protege for the last 6 months and
>> have slow started to have more and more issues with how Protege saves
>> owl files.
>>
>> The project I'm on is maintained in a perforce repository and  
>> branched
>> as required, once a branch is finished or stable it is merged back
>> into the main branch. The issue comes when you try to merge owl  
>> files.
>> A merge is takes about 3 days, of which over 2.5 days is just sorting
>> out manually merging the owl files. Identifying changes which have
>> occurred in both branches and then implementing those changes.
>>
>> Is there a way of getting Protege to group and sort
>> objects/properties/attributes when it saves and owl file. I don't  
>> mind
>> how its ordered or grouped I'd just like some conformity to how it
>> does it.
>>
>> John Patrick
>> _______________________________________________
>> protege-discussion mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>
>> Instructions for unsubscribing: http://protege.stanford.edu/doc/ 
>> faq.html#01a.03
>>
>
>
> --
> Samson Tu                    email: [hidden email]
> Senior Research Scientist    web: www.stanford.edu/~swt/
> Stanford Medical Informatics phone: 1-650-725-3391
> Stanford University          fax: 1-650-725-7944
>
> _______________________________________________
> protege-discussion mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/ 
> faq.html#01a.03

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Source Control Mightmare

Jan Henke
Hi Thomas,

there can be several different serializations of an ontology all of them
having the same semantics. Therefore it would be not correct to forbid any
of them. For this reason, versioning just on the basis of some serialization
doesn't work for ontologies. However there are approaches for solving this.
See for instance http://iswc2006.semanticweb.org/items/Noy2006fj.pdf

Best regards
Jan


 

> -----Ursprüngliche Nachricht-----
> Von: [hidden email]
> [mailto:[hidden email]] Im
> Auftrag von Thomas Russ
> Gesendet: Dienstag, 30. Jänner 2007 18:59
> An: User support for Core Protege and the Protege-Frames editor
> Betreff: Re: [protege-discussion] Source Control Mightmare
>
>
> On Jan 30, 2007, at 9:45 AM, Samson Tu wrote:
>
> >
> > Have you tried to do the version comparison and merging using the
> > Prompt plugin that comes with Protege? That's what the plugin is
> > designed to do.
>
> That certainly helps with the merging step, but it doesn't
> solve the problem of a real impedance mismatch between the
> somewhat random order terms are saved by Protege and the
> assumption of small, incremental and local changes that is
> made by source control systems like CVS or SVN.
>
> Defining a canonical order in which to save information would
> greatly aid in using such source control tools with Protege
> ontologies.  This would be a big help for large projects, so
> I need to express my support for John's feature request.
>
> It wouldn't really be all that hard to do, either.  All that
> is required is to decide on the order to save (i.e., Classes
> or Properties/Slots first) and then sort the objects by their
> name before saving.  I have done this for an export plugin I
> wrote and it isn't all that difficult.  An additional sort on
> template slot information for classes will also cause the
> substructure to be sorted.
>
> That would at least cause the terms to appear in the same
> order when there are no changes and that would go a long way
> to making the resulting files work well with source control tools.
>
> If there is concern about the cost of sorting the objects
> each time one saves, then this could be addressed by
> introducing a configuration property that determines if one
> wants sorted output or not.  My feeling is that sorting
> doesn't add much overhead on saving, but I haven't used this
> on very large ontologies.
>
> But I think this would be a good feature to include in the
> next version of Protege.
>
>
> >
> > John Patrick wrote:
> >> Greetings,
> >>
> >> I've searched the message archives but have been unable to find
> >> similar problems. I've been using Protege for the last 6
> months and
> >> have slow started to have more and more issues with how
> Protege saves
> >> owl files.
> >>
> >> The project I'm on is maintained in a perforce repository and
> >> branched as required, once a branch is finished or stable it is
> >> merged back into the main branch. The issue comes when you try to
> >> merge owl files.
> >> A merge is takes about 3 days, of which over 2.5 days is
> just sorting
> >> out manually merging the owl files. Identifying changes which have
> >> occurred in both branches and then implementing those changes.
> >>
> >> Is there a way of getting Protege to group and sort
> >> objects/properties/attributes when it saves and owl file. I don't
> >> mind how its ordered or grouped I'd just like some
> conformity to how
> >> it does it.
> >>
> >> John Patrick
> >> _______________________________________________
> >> protege-discussion mailing list
> >> [hidden email]
> >> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> >>
> >> Instructions for unsubscribing: http://protege.stanford.edu/doc/
> >> faq.html#01a.03
> >>
> >
> >
> > --
> > Samson Tu                    email: [hidden email]
> > Senior Research Scientist    web: www.stanford.edu/~swt/
> > Stanford Medical Informatics phone: 1-650-725-3391
> > Stanford University          fax: 1-650-725-7944
> >
> > _______________________________________________
> > protege-discussion mailing list
> > [hidden email]
> > https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> >
> > Instructions for unsubscribing: http://protege.stanford.edu/doc/
> > faq.html#01a.03
>
> _______________________________________________
> protege-discussion mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing:
> http://protege.stanford.edu/doc/faq.html#01a.03 
>

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Source Control Mightmare

Mark Feblowitz
Ah - I look forward to reading that paper.

I've had the same challenge when using ClearCase with our many Owl ontologies.

I have often noticed issues - even in Protege Owl
- with the way ontologies are serialized to files.

It seems to be a convenience and also an
efficiency to be able to write any of a number of
semantically equivalent but differently ordered
Owl assertions to a file. Yet it does play havoc on xml  file comparators.

Specifically in Protege, I've noticed that a the
order of at least some parts of the serialized
owl files can be mostly or totally reversed each
time the ontology is serialized to a file. When
an owl file is later read back in, the order in
which a "multi-parent" individual is associated
with its various parents is also reversed,
changing the behavior of the instance editor,
which seems to favor the first parent in the set of  asserted parents.

It occurred to me that one might be able to write
a separate tool that takes in an owl file and
reorders it into some repeatable uniform order.
It wouldn't be easy, though, since in many cases
there is no convenient way to determine a
repeatable ordering of elements (i.e., you
couldn't know what the original/intended ordering
of class membership was, without some additional
annotation). You'd have to use some convention,
e.g., alphabetically sorting the node in the
tree. Not pretty, and possibly not completely
repeatable, but even partial uniformity would help with the merge problem.

It would be better if there were a uniform
serialization technique built into jena,
switch-controllable in Protege. The default could
be for efficient saves, but switchable to perform
(somewhat) uniformly ordered saves. I assume that
a special, owl-specific serializer would be
necessary, if the model was known to be Owl RDF.

I'm not saying that anybody should forbid other
techniques. What's needed is a practical means of
improving the situation, for those of us whole
have to maintain complex ontologies in a production setting.

Is this at all feasible?

Mark

At 05:24 AM 1/31/2007, Jan Henke wrote:

>Hi Thomas,
>
>there can be several different serializations of an ontology all of them
>having the same semantics. Therefore it would be not correct to forbid any
>of them. For this reason, versioning just on the basis of some serialization
>doesn't work for ontologies. However there are approaches for solving this.
>See for instance http://iswc2006.semanticweb.org/items/Noy2006fj.pdf
>
>Best regards
>Jan
>
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: [hidden email]
> > [mailto:[hidden email]] Im
> > Auftrag von Thomas Russ
> > Gesendet: Dienstag, 30. Jänner 2007 18:59
> > An: User support for Core Protege and the Protege-Frames editor
> > Betreff: Re: [protege-discussion] Source Control Mightmare
> >
> >
> > On Jan 30, 2007, at 9:45 AM, Samson Tu wrote:
> >
> > >
> > > Have you tried to do the version comparison and merging using the
> > > Prompt plugin that comes with Protege? That's what the plugin is
> > > designed to do.
> >
> > That certainly helps with the merging step, but it doesn't
> > solve the problem of a real impedance mismatch between the
> > somewhat random order terms are saved by Protege and the
> > assumption of small, incremental and local changes that is
> > made by source control systems like CVS or SVN.
> >
> > Defining a canonical order in which to save information would
> > greatly aid in using such source control tools with Protege
> > ontologies.  This would be a big help for large projects, so
> > I need to express my support for John's feature request.
> >
> > It wouldn't really be all that hard to do, either.  All that
> > is required is to decide on the order to save (i.e., Classes
> > or Properties/Slots first) and then sort the objects by their
> > name before saving.  I have done this for an export plugin I
> > wrote and it isn't all that difficult.  An additional sort on
> > template slot information for classes will also cause the
> > substructure to be sorted.
> >
> > That would at least cause the terms to appear in the same
> > order when there are no changes and that would go a long way
> > to making the resulting files work well with source control tools.
> >
> > If there is concern about the cost of sorting the objects
> > each time one saves, then this could be addressed by
> > introducing a configuration property that determines if one
> > wants sorted output or not.  My feeling is that sorting
> > doesn't add much overhead on saving, but I haven't used this
> > on very large ontologies.
> >
> > But I think this would be a good feature to include in the
> > next version of Protege.
> >
> >
> > >
> > > John Patrick wrote:
> > >> Greetings,
> > >>
> > >> I've searched the message archives but have been unable to find
> > >> similar problems. I've been using Protege for the last 6
> > months and
> > >> have slow started to have more and more issues with how
> > Protege saves
> > >> owl files.
> > >>
> > >> The project I'm on is maintained in a perforce repository and
> > >> branched as required, once a branch is finished or stable it is
> > >> merged back into the main branch. The issue comes when you try to
> > >> merge owl files.
> > >> A merge is takes about 3 days, of which over 2.5 days is
> > just sorting
> > >> out manually merging the owl files. Identifying changes which have
> > >> occurred in both branches and then implementing those changes.
> > >>
> > >> Is there a way of getting Protege to group and sort
> > >> objects/properties/attributes when it saves and owl file. I don't
> > >> mind how its ordered or grouped I'd just like some
> > conformity to how
> > >> it does it.
> > >>
> > >> John Patrick
> > >> _______________________________________________
> > >> protege-discussion mailing list
> > >> [hidden email]
> > >> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> > >>
> > >> Instructions for unsubscribing: http://protege.stanford.edu/doc/
> > >> faq.html#01a.03
> > >>
> > >
> > >
> > > --
> > > Samson Tu                    email: [hidden email]
> > > Senior Research Scientist    web: www.stanford.edu/~swt/
> > > Stanford Medical Informatics phone: 1-650-725-3391
> > > Stanford University          fax: 1-650-725-7944
> > >
> > > _______________________________________________
> > > protege-discussion mailing list
> > > [hidden email]
> > > https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> > >
> > > Instructions for unsubscribing: http://protege.stanford.edu/doc/
> > > faq.html#01a.03
> >
> > _______________________________________________
> > protege-discussion mailing list
> > [hidden email]
> > https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> >
> > Instructions for unsubscribing:
> > http://protege.stanford.edu/doc/faq.html#01a.03
> >
>
>_______________________________________________
>protege-discussion mailing list
>[hidden email]
>https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
>Instructions for unsubscribing:
>http://protege.stanford.edu/doc/faq.html#01a.03

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Source Control Mightmare

Thomas Russ
In reply to this post by Jan Henke
Shifting this also over to OWL, since at least one reply ended up  
there...

On Jan 31, 2007, at 2:24 AM, Jan Henke wrote:

> Hi Thomas,
>
> there can be several different serializations of an ontology all of  
> them
> having the same semantics. Therefore it would be not correct to  
> forbid any
> of them. For this reason, versioning just on the basis of some  
> serialization
> doesn't work for ontologies.

I'm not completely convinced.

Sure, there are different, semantically equivalent serializations
possible, but in practice a given tool will deterministically
produce just one of them.  Protege, for example, will not choose
arbitrarily different serializations each time it saves an ontology.

That opens the door to using a simple solution of choosing the
order of saving objects.  That will generally produce files that
behave much better with respect to source control systems than
the current behavior, in which there the order is determined by
hash code values.

OK, given the strategy of including the full definition of an
object when first mentioned (in the OWL saves), this won't always
work, since a new reference to an existing class or property may
cause it to move in the saved file, but for the bulk of items
in an ontology that don't change between versions, using a
canonical order for writing would allow simple source control
difference matching to work better.

Seeing as how it isn't difficult to implement the sorting step
before writing out the ontology, I think it would be a useful
enhancement.

> However there are approaches for solving this.
> See for instance http://iswc2006.semanticweb.org/items/Noy2006fj.pdf

This is an interesting paper, and certainly does a better job
of addressing the change management issues for ontologies than
a standard source control system (SCS).

However, SCS technology is widely used, and particularly where
the ontology is just one part of a complete software system, there
is a desire to be able to use only a single tool.  So trying to
make the saved files work more easily with SCS tools would be
a good thing from the point of view of practice.

>
> Best regards
> Jan
>
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: [hidden email]
>> [mailto:[hidden email]] Im
>> Auftrag von Thomas Russ
>> Gesendet: Dienstag, 30. Jänner 2007 18:59
>> An: User support for Core Protege and the Protege-Frames editor
>> Betreff: Re: [protege-discussion] Source Control Mightmare
>>
>>
>> On Jan 30, 2007, at 9:45 AM, Samson Tu wrote:
>>
>>>
>>> Have you tried to do the version comparison and merging using the
>>> Prompt plugin that comes with Protege? That's what the plugin is
>>> designed to do.
>>
>> That certainly helps with the merging step, but it doesn't
>> solve the problem of a real impedance mismatch between the
>> somewhat random order terms are saved by Protege and the
>> assumption of small, incremental and local changes that is
>> made by source control systems like CVS or SVN.
>>
>> Defining a canonical order in which to save information would
>> greatly aid in using such source control tools with Protege
>> ontologies.  This would be a big help for large projects, so
>> I need to express my support for John's feature request.
>>
>> It wouldn't really be all that hard to do, either.  All that
>> is required is to decide on the order to save (i.e., Classes
>> or Properties/Slots first) and then sort the objects by their
>> name before saving.  I have done this for an export plugin I
>> wrote and it isn't all that difficult.  An additional sort on
>> template slot information for classes will also cause the
>> substructure to be sorted.
>>
>> That would at least cause the terms to appear in the same
>> order when there are no changes and that would go a long way
>> to making the resulting files work well with source control tools.
>>
>> If there is concern about the cost of sorting the objects
>> each time one saves, then this could be addressed by
>> introducing a configuration property that determines if one
>> wants sorted output or not.  My feeling is that sorting
>> doesn't add much overhead on saving, but I haven't used this
>> on very large ontologies.
>>
>> But I think this would be a good feature to include in the
>> next version of Protege.
>>
>>
>>>
>>> John Patrick wrote:
>>>> Greetings,
>>>>
>>>> I've searched the message archives but have been unable to find
>>>> similar problems. I've been using Protege for the last 6
>> months and
>>>> have slow started to have more and more issues with how
>> Protege saves
>>>> owl files.
>>>>
>>>> The project I'm on is maintained in a perforce repository and
>>>> branched as required, once a branch is finished or stable it is
>>>> merged back into the main branch. The issue comes when you try to
>>>> merge owl files.
>>>> A merge is takes about 3 days, of which over 2.5 days is
>> just sorting
>>>> out manually merging the owl files. Identifying changes which have
>>>> occurred in both branches and then implementing those changes.
>>>>
>>>> Is there a way of getting Protege to group and sort
>>>> objects/properties/attributes when it saves and owl file. I don't
>>>> mind how its ordered or grouped I'd just like some
>> conformity to how
>>>> it does it.
>>>>
>>>> John Patrick
>>>> _______________________________________________
>>>> protege-discussion mailing list
>>>> [hidden email]
>>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>>
>>>> Instructions for unsubscribing: http://protege.stanford.edu/doc/
>>>> faq.html#01a.03
>>>>
>>>
>>>
>>> --
>>> Samson Tu                    email: [hidden email]
>>> Senior Research Scientist    web: www.stanford.edu/~swt/
>>> Stanford Medical Informatics phone: 1-650-725-3391
>>> Stanford University          fax: 1-650-725-7944
>>>
>>> _______________________________________________
>>> protege-discussion mailing list
>>> [hidden email]
>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>
>>> Instructions for unsubscribing: http://protege.stanford.edu/doc/
>>> faq.html#01a.03
>>
>> _______________________________________________
>> protege-discussion mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>
>> Instructions for unsubscribing:
>> http://protege.stanford.edu/doc/faq.html#01a.03
>>
>
> _______________________________________________
> protege-discussion mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/ 
> faq.html#01a.03

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: Source Control Mightmare

Jan Henke
> However, SCS technology is widely used, and particularly
> where the ontology is just one part of a complete software
> system, there is a desire to be able to use only a single
> tool.  So trying to make the saved files work more easily
> with SCS tools would be a good thing from the point of view
> of practice.

Then you might be interested in SemVersion [1].

Quote: "A possible way to compute a semantic diff in RDFS is thus to
materialize the complete entailment (transitive closure) and then perform a
structural diff, like it is done in SemVersion."

Best regards
Jan

[1] Max Völkel, Tudor Groza
SemVersion: An RDF-based Ontology Versioning System
In Proceedings of IADIS International Conference on WWW/Internet, volume 1,
pp. 195-202. IADIS, IADIS, Murcia, Spain, October 2006.
(http://www.xam.de/2006/10-SemVersion-ICIW2006.pdf)











>
> >
> > Best regards
> > Jan
> >
> >
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: [hidden email]
> >> [mailto:[hidden email]]
> Im Auftrag
> >> von Thomas Russ
> >> Gesendet: Dienstag, 30. Jänner 2007 18:59
> >> An: User support for Core Protege and the Protege-Frames editor
> >> Betreff: Re: [protege-discussion] Source Control Mightmare
> >>
> >>
> >> On Jan 30, 2007, at 9:45 AM, Samson Tu wrote:
> >>
> >>>
> >>> Have you tried to do the version comparison and merging using the
> >>> Prompt plugin that comes with Protege? That's what the plugin is
> >>> designed to do.
> >>
> >> That certainly helps with the merging step, but it doesn't
> solve the
> >> problem of a real impedance mismatch between the somewhat random
> >> order terms are saved by Protege and the assumption of small,
> >> incremental and local changes that is made by source
> control systems
> >> like CVS or SVN.
> >>
> >> Defining a canonical order in which to save information
> would greatly
> >> aid in using such source control tools with Protege
> ontologies.  This
> >> would be a big help for large projects, so I need to express my
> >> support for John's feature request.
> >>
> >> It wouldn't really be all that hard to do, either.  All that is
> >> required is to decide on the order to save (i.e., Classes or
> >> Properties/Slots first) and then sort the objects by their name
> >> before saving.  I have done this for an export plugin I
> wrote and it
> >> isn't all that difficult.  An additional sort on template slot
> >> information for classes will also cause the substructure to be
> >> sorted.
> >>
> >> That would at least cause the terms to appear in the same
> order when
> >> there are no changes and that would go a long way to making the
> >> resulting files work well with source control tools.
> >>
> >> If there is concern about the cost of sorting the objects
> each time
> >> one saves, then this could be addressed by introducing a
> >> configuration property that determines if one wants sorted
> output or
> >> not.  My feeling is that sorting doesn't add much overhead
> on saving,
> >> but I haven't used this on very large ontologies.
> >>
> >> But I think this would be a good feature to include in the next
> >> version of Protege.
> >>
> >>
> >>>
> >>> John Patrick wrote:
> >>>> Greetings,
> >>>>
> >>>> I've searched the message archives but have been unable to find
> >>>> similar problems. I've been using Protege for the last 6
> >> months and
> >>>> have slow started to have more and more issues with how
> >> Protege saves
> >>>> owl files.
> >>>>
> >>>> The project I'm on is maintained in a perforce repository and
> >>>> branched as required, once a branch is finished or stable it is
> >>>> merged back into the main branch. The issue comes when
> you try to
> >>>> merge owl files.
> >>>> A merge is takes about 3 days, of which over 2.5 days is
> >> just sorting
> >>>> out manually merging the owl files. Identifying changes
> which have
> >>>> occurred in both branches and then implementing those changes.
> >>>>
> >>>> Is there a way of getting Protege to group and sort
> >>>> objects/properties/attributes when it saves and owl
> file. I don't
> >>>> mind how its ordered or grouped I'd just like some
> >> conformity to how
> >>>> it does it.
> >>>>
> >>>> John Patrick
> >>>> _______________________________________________
> >>>> protege-discussion mailing list
> >>>> [hidden email]
> >>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> >>>>
> >>>> Instructions for unsubscribing: http://protege.stanford.edu/doc/
> >>>> faq.html#01a.03
> >>>>
> >>>
> >>>
> >>> --
> >>> Samson Tu                    email: [hidden email]
> >>> Senior Research Scientist    web: www.stanford.edu/~swt/
> >>> Stanford Medical Informatics phone: 1-650-725-3391
> >>> Stanford University          fax: 1-650-725-7944
> >>>
> >>> _______________________________________________
> >>> protege-discussion mailing list
> >>> [hidden email]
> >>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> >>>
> >>> Instructions for unsubscribing: http://protege.stanford.edu/doc/
> >>> faq.html#01a.03
> >>
> >> _______________________________________________
> >> protege-discussion mailing list
> >> [hidden email]
> >> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> >>
> >> Instructions for unsubscribing:
> >> http://protege.stanford.edu/doc/faq.html#01a.03
> >>
> >
> > _______________________________________________
> > protege-discussion mailing list
> > [hidden email]
> > https://mailman.stanford.edu/mailman/listinfo/protege-discussion
> >
> > Instructions for unsubscribing: http://protege.stanford.edu/doc/
> > faq.html#01a.03
>
> _______________________________________________
> protege-discussion mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing:
> http://protege.stanford.edu/doc/faq.html#01a.03 
>

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

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03 
Reply | Threaded
Open this post in threaded view
|

Re: [protege-owl] Source Control Mightmare

Thomas Russ

On Feb 1, 2007, at 2:03 AM, Jan Henke wrote:

>> However, SCS technology is widely used, and particularly
>> where the ontology is just one part of a complete software
>> system, there is a desire to be able to use only a single
>> tool.  So trying to make the saved files work more easily
>> with SCS tools would be a good thing from the point of view
>> of practice.
>
> Then you might be interested in SemVersion [1].
>
> Quote: "A possible way to compute a semantic diff in RDFS is thus to
> materialize the complete entailment (transitive closure) and then  
> perform a
> structural diff, like it is done in SemVersion."

Such versioning is, of course, exactly the right sort of thing
for RDF-based ontologies.  But it doesn't seem to be set up to
handle source code files that aren't encoded in RDF triples.

(Aside:  There is also the diff issue for source code if all
  you do is move the location of methods inside an object, but...)

What would be useful to have as a tool is an integrated solution
that handles both traditional text-based diffs and merges as well
as structural diffs and merges for RDF-encoded information.

I'm sure that such an integrated tool will emerge.  I'm just
wishing it were already here....

>
> Best regards
> Jan
>
> [1] Max Völkel, Tudor Groza
> SemVersion: An RDF-based Ontology Versioning System
> In Proceedings of IADIS International Conference on WWW/Internet,  
> volume 1,
> pp. 195-202. IADIS, IADIS, Murcia, Spain, October 2006.
> (http://www.xam.de/2006/10-SemVersion-ICIW2006.pdf)
>
>
>
>
>
>
>
>
>
>
>
>>
>>>
>>> Best regards
>>> Jan
>>>
>>>
>>>
>>>
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: [hidden email]
>>>> [mailto:[hidden email]]
>> Im Auftrag
>>>> von Thomas Russ
>>>> Gesendet: Dienstag, 30. Jänner 2007 18:59
>>>> An: User support for Core Protege and the Protege-Frames editor
>>>> Betreff: Re: [protege-discussion] Source Control Mightmare
>>>>
>>>>
>>>> On Jan 30, 2007, at 9:45 AM, Samson Tu wrote:
>>>>
>>>>>
>>>>> Have you tried to do the version comparison and merging using the
>>>>> Prompt plugin that comes with Protege? That's what the plugin is
>>>>> designed to do.
>>>>
>>>> That certainly helps with the merging step, but it doesn't
>> solve the
>>>> problem of a real impedance mismatch between the somewhat random
>>>> order terms are saved by Protege and the assumption of small,
>>>> incremental and local changes that is made by source
>> control systems
>>>> like CVS or SVN.
>>>>
>>>> Defining a canonical order in which to save information
>> would greatly
>>>> aid in using such source control tools with Protege
>> ontologies.  This
>>>> would be a big help for large projects, so I need to express my
>>>> support for John's feature request.
>>>>
>>>> It wouldn't really be all that hard to do, either.  All that is
>>>> required is to decide on the order to save (i.e., Classes or
>>>> Properties/Slots first) and then sort the objects by their name
>>>> before saving.  I have done this for an export plugin I
>> wrote and it
>>>> isn't all that difficult.  An additional sort on template slot
>>>> information for classes will also cause the substructure to be
>>>> sorted.
>>>>
>>>> That would at least cause the terms to appear in the same
>> order when
>>>> there are no changes and that would go a long way to making the
>>>> resulting files work well with source control tools.
>>>>
>>>> If there is concern about the cost of sorting the objects
>> each time
>>>> one saves, then this could be addressed by introducing a
>>>> configuration property that determines if one wants sorted
>> output or
>>>> not.  My feeling is that sorting doesn't add much overhead
>> on saving,
>>>> but I haven't used this on very large ontologies.
>>>>
>>>> But I think this would be a good feature to include in the next
>>>> version of Protege.
>>>>
>>>>
>>>>>
>>>>> John Patrick wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> I've searched the message archives but have been unable to find
>>>>>> similar problems. I've been using Protege for the last 6
>>>> months and
>>>>>> have slow started to have more and more issues with how
>>>> Protege saves
>>>>>> owl files.
>>>>>>
>>>>>> The project I'm on is maintained in a perforce repository and
>>>>>> branched as required, once a branch is finished or stable it is
>>>>>> merged back into the main branch. The issue comes when
>> you try to
>>>>>> merge owl files.
>>>>>> A merge is takes about 3 days, of which over 2.5 days is
>>>> just sorting
>>>>>> out manually merging the owl files. Identifying changes
>> which have
>>>>>> occurred in both branches and then implementing those changes.
>>>>>>
>>>>>> Is there a way of getting Protege to group and sort
>>>>>> objects/properties/attributes when it saves and owl
>> file. I don't
>>>>>> mind how its ordered or grouped I'd just like some
>>>> conformity to how
>>>>>> it does it.
>>>>>>
>>>>>> John Patrick
>>>>>> _______________________________________________
>>>>>> protege-discussion mailing list
>>>>>> [hidden email]
>>>>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>>>>
>>>>>> Instructions for unsubscribing: http://protege.stanford.edu/doc/
>>>>>> faq.html#01a.03
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Samson Tu                    email: [hidden email]
>>>>> Senior Research Scientist    web: www.stanford.edu/~swt/
>>>>> Stanford Medical Informatics phone: 1-650-725-3391
>>>>> Stanford University          fax: 1-650-725-7944
>>>>>
>>>>> _______________________________________________
>>>>> protege-discussion mailing list
>>>>> [hidden email]
>>>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>>>
>>>>> Instructions for unsubscribing: http://protege.stanford.edu/doc/
>>>>> faq.html#01a.03
>>>>
>>>> _______________________________________________
>>>> protege-discussion mailing list
>>>> [hidden email]
>>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>>
>>>> Instructions for unsubscribing:
>>>> http://protege.stanford.edu/doc/faq.html#01a.03
>>>>
>>>
>>> _______________________________________________
>>> protege-discussion mailing list
>>> [hidden email]
>>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>>
>>> Instructions for unsubscribing: http://protege.stanford.edu/doc/
>>> faq.html#01a.03
>>
>> _______________________________________________
>> protege-discussion mailing list
>> [hidden email]
>> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>>
>> Instructions for unsubscribing:
>> http://protege.stanford.edu/doc/faq.html#01a.03
>>
>
> _______________________________________________
> protege-discussion mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-discussion
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/ 
> faq.html#01a.03

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

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