Hi Jody, if you want to send me the (Jena?) code that does the sorting, then I can likely integrate it into the next TBC release.
Thanks, Holger On Dec 4, 2008, at 4:45 PM, Jody wrote: > > I've been trying to solve the same problem. For our use it seems N3 > is going to work. One issue I've found going this route is blank > nodes like subClassOf restrictions aren't ordered within a class > definition. It's odd that the primary resource and direct statements > are alphabetized but the sorting does not extend further. This was > fairly easily fixed by writing a parser to sort the first couple > levels of restrictions within each class definition. Complex union/ > intersection restrictions may still pose a problem. It would be great > if this post-jena processing was done each time I save by TBC. I > started incorporating this logic as a plug-in, but now we are looking > to incorporate the sort-process (written in Java) as an auto-run > through Tortoise SVN on commit. Anyone have advice on how to > implement that? > > Note that the restriction below come out in arbitrary order. > > carads:CarAd > a owl:Class ; > rdfs:subClassOf > [ a owl:Restriction ; > owl:maxCardinality "1"^^xsd:nonNegativeInteger ; > owl:onProperty carads:hasMileage > ] ; > rdfs:subClassOf > [ a owl:Restriction ; > owl:allValuesFrom carads:Feature ; > owl:onProperty carads:hasFeature > ] ; > rdfs:subClassOf > [ a owl:Restriction ; > owl:minCardinality "0"^^xsd:nonNegativeInteger ; > owl:onProperty carads:hasPhoneNr > ] ; > rdfs:subClassOf > [ a owl:Restriction ; > owl:maxCardinality "1"^^xsd:nonNegativeInteger ; > owl:onProperty carads:hasPrice > ] . > > On Dec 4, 4:46 pm, "Johnrobert Gardner" <[EMAIL PROTECTED]> > wrote: >> Hey folks- >> >> At Digitas for a client we had this problem - both using Perforce >> and SVN. >> E.g., making a change of one letter to the ontology caused that >> order to >> change and the versioning software agonized to resolve all the >> changes. >> >> We used the Orangevolt XSLT plugin, we all had to use the same >> processor >> (you'll need to tinker to see whether Saxon or Xalan is better, we >> settled >> on Saxon). Our XSLT does a simple sort to alphabetize all the >> triples based >> on the attribute for :about >> >> We utilized every sincle white-space handling gizmo - both elements >> and >> functions in the script which is maybe one template about 7 lines >> long. Run >> it before each commit, and the versioning will work lovely. >> >> Don't use the Eclipse internal sorter, it's SLOWWWWWWWW with big >> ontologies. The XSLT script can be kept in your SVN too, so >> commiting is >> just File/Run as/Orangevolt XSLT in your Navigator, be sure to do >> setup to >> NOT change the file extension, and appropriately save the >> translated/processed version in the right place for SVN. >> >> Hope this helps, >> >> jr >> >> -- >> John Robert Gardner, Ph.D., NR-EMT >> VP/Director: Content Management Services >> Digitas >> >> Views and opinions expressed or implied in this email are >> independent of >> National EMT Registry, Digitas, Publicis, Prodigious and/or their >> clients >> and partners. >> >> On Thu, Dec 4, 2008 at 11:23 AM, Scott Henninger >> <[EMAIL PROTECTED] >> >>> wrote: >> >>> Matt, James; When working with XML, version control features >>> (such as >>> comparing changes) is in general difficult, perhaps impossible. >>> Note >>> that databases have problems with these kinds of features as well. >> >>> One idea is to use n3 instead of XML. n3 has a much more regular >>> structure and won't re-order resources in different ways. It may not >>> be a full solution for your purposes but will get you a lot closer >>> to >>> the ability to, for example, compare file versions. >> >>> -- Scott >> >>> On Dec 4, 8:31 am, jlapalme <[EMAIL PROTECTED]> wrote: >>>> Personnally, >> >>>> I have been searching for some time now and I have found nothing. >> >>>> If you are able to share your code for comparing two models, I >>>> would >>>> be very greatful. >> >>>> Cheers, >> >>>> James >> >>>> On Dec 3, 5:25 pm, Matt <[EMAIL PROTECTED]> wrote: >> >>>>> Hey, hopefully someone in the community has solved this >>>>> problem. We >>>>> have several models that are large enough to still keep in a file >>>>> system. We are versioning these models using SVN. JENA >>>>> standard says >>>>> that models do not have to be written out in any consistent >>>>> order. As >>>>> a result, SVN seems to just consider .owl files .xml files and >>>>> explodes because the ordering of the .owl files changes anytime >>>>> I add >>>>> stuff to it (either in code or in TBC). >> >>>>> I have code that I can run to compare 2 models using JENA and >>>>> tell me >>>>> what statements are in one model but not in the other. So I can >>>>> then >>>>> manually merge the files. However, someone has to have done >>>>> this in a >>>>> more elegant and user friendly capacity. Perhaps extending the >>>>> default comparison modules in subclipse/subversive? > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=en -~----------~----~----~----~------~----~------~--~---
