hmm, that got me thinking about the rule that made this happen. so according to rdfs inferencing semantics, if a property has a class as a domain, then any instance with that property, will be determined to be of that class?
ok, but what If I specify more than one domain for that property? in my example, I went in and added datafield as a domain for the tag property. all that did was, now both the controlfield AND datafield element instances have type controlfield and datafield. that logic doesn't make sense to me, or at least it implies that I rarely if ever can have multiple domains for a property. if I ever want to have multiple domains for a property, then I'll need to create a supertype over those properties, and make that supertype the domain. like, I may want to say "both horses and cars have passengers", but that doesn't imply "anything that has passengers is both a horse AND a car." but according to this inferencing, it would. What I would have to do is create a "passengertaker" type, put horse and car under it, and make passengertaker the domain of "takes passengers." learn something new every day, i do. given that kind of strictness, it seems extra important that the element atttributes not be merged into one property, just because they share the same name. On Oct 10, 9:33 am, donundeen <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
