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
-~----------~----~----~----~------~----~------~--~---
