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-owl] Source Control Mightmare

Thomas Russ tar at ISI.EDU
Thu Feb 1 09:35:13 PST 2007


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: protege-discussion-bounces at mailman.stanford.edu
>>>> [mailto:protege-discussion-bounces at mailman.stanford.edu]
>> 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
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Samson Tu                    email: swt at stanford.edu
>>>>> 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
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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