your last statement seems to me to make the most sense. two attributes with the same name, in different elements, really have nothing to do with each other, that's what you're saying is happening, right?
and I see that in my data, both my elements datafield and controlfield have the same attribute "tag", but the PROPERTY for both is file:///testMarc/sargent1record.xml#tag-marccontrolfield that name indicating that it came from controlfield, even though datafield has the same property. yeah, that doesn't make sense. Is this something that is likely to be fixed soon? What I really want is for the two different elements to have differerent attribute property names, as that seems like the most "correct" approach. thanks again! On Oct 9, 6:27 pm, Holger Knublauch <[EMAIL PROTECTED]> wrote: > Hi Don, > > thanks for reporting this problematic case. The issue is that the > Semantic XML importer currently merges together multiple XML > attributes into a single datatype property, if the attribute name is > identical. Since the "first" occurrence of the attribute will be > covered with an rdfs:domain triple, inference engines will merge their > instances together (using RDFS inferencing semantics). > > Work-arounds are: > > 1) remove the rdfs:domain statements before inferencing > > 2) prepare a separate ontology which only has the class and property > definitions in them. Then import the .xml instances file into that > ontology. It will then pick up the property definitions from the > ontology and won't create new ones. This approach is for example used > when you open XHTML files with semantic XML - it will use a pre- > defined xhtml ontology from TBC. Note that this approach currently has > the limitation that it will only work "right" when you the ontology is > loaded before the instance file(s). For example, drag the .xml file > into the Imports view when the ontology is open. > > I need think more about which policy this feature should have to avoid > overlapping domain problems. Possible the system should simply create > a new property for each new Element type by default. > > Holger > > On Oct 9, 2008, at 11:51 AM, donundeen wrote: > > > > > Hi, I hope I can explain this well enough so bear with me: > > > I've got an xml file that looks like this: > > <?xml version="1.0" encoding="UTF-8" ?> > > <marc:collection xmlns:marc="http://www.loc.gov/MARC21/slim" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > > xsi:schemaLocation="http://www.loc.gov/MARC21/slim > >http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd"> > > <marc:record> > > <marc:leader>00259nz a2200109n 4500</marc:leader> > > <marc:controlfield tag="001">n 50019335 </marc:controlfield> > > <marc:controlfield tag="005">19840322000000.0</ > > marc:controlfield> > > <marc:controlfield tag="008">800501n| acannaab| |n aaa </ > > marc:controlfield> > > <marc:datafield tag="010" ind1=" " ind2=" "> > > <marc:subfield code="a">n 50019335</marc:subfield> > > </marc:datafield> > > <marc:datafield tag="040" ind1=" " ind2=" "> > > <marc:subfield code="a">DLC</marc:subfield> > > <marc:subfield code="c">DLC</marc:subfield> > > </marc:datafield> > > <marc:datafield tag="100" ind1="1" ind2=" "> > > <marc:subfield code="a">Sargent, John Singer,</ > > marc:subfield> > > <marc:subfield code="d">1856-1925.</marc:subfield> > > </marc:datafield> > > <marc:datafield tag="902" ind1=" " ind2=" "> > > <marc:subfield code="a">060517</marc:subfield> > > </marc:datafield> > > </marc:record> > > </marc:collection> > > > When I import the file into a TBC project, I see that there are types > > added as I expect: > > marc:collection > > marc:controlfield > > marc:datafield > > etc. > > > if I click on marc:datafield in the class tree, I can see the 4 > > instances of marc:datafield elements, and if I click on > > marc:controlfield, I can see the 3 instances of controlfield elements. > > > However, if I do "run inferencing", things get all out of whack: > > - now, all my datafield elements have TWO types: marc:controlfield, > > AND marc:datafield > > > also, on this small file, the controlfield elements don't also get > > marc:datafield, but on larger files, they do. > > > Any ideas what's going on? this sure seems like a bug, but maybe I'm > > doing something wrong. > > Perhaps someone else can try loading this file and running > > inferencing, to see what happens? > > > thanks very much! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
