system. However, until such a tool is available, I can also see that
> 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-owl mailing list
>
[hidden email]
>
https://mailman.stanford.edu/mailman/listinfo/protege-owl>
> Instructions for unsubscribing:
http://protege.stanford.edu/doc/faq.html#01a.03
>
>