Don, According to RDFS semantics if there are two triples:
P rdfs:domain A And P rdfs:Domain B Then from a triple X P Y, it will be inferred that X rdf:type A and X rdf:type B Basically, domain and range declarations are global - all the declarations made will be taken into account any time a property is used. The use of domains and ranges together with trying to reuse ontologies from others or modularize your ontologies will often lead to unexpected results as you have discovered. This does not mean you can not re-use properties. You can use local restrictions on classes instead of rdfs:domain and rdfs:range. Restrictions are local to members of a particular class. Also a restriction made for a class implies that it is in effect for its subclasses while a domain statement about a class does not imply anything about the subclasses. So, when you say that hasPassenger rdfs:domain PassengerTaker, this does not mean that Horse or Car are in the domain of hasPassenger even though they are subclasses of PassengerTaker. What you have said is that if X hasPassenger Y then X rdf:type PassengerTaker, but it does not mean that X is either a Horse or a Car. Of course, you can use this property with horses and cars, but then you can use it with anything - in RDF anyone can say anything about anything. As a result, saying that hasPassenger rdfs:domain PassengerTaker and making Horse and Car its subclasses does not really serves any purpose as far as horses and cars go. For your example, I would not use any domains but the hasPassenger, but rather declare restrictions for Horse and Car class. If you are ready to commit to the fact that passengers are people, it could be allValuesFrom Person restriction. If you are not, this could be a minCardinality restriction. Another option is to use distinct properties and then make them all a subproperty of a parent property with the parent property having no domains or ranges. This way, you can query for all passengers, irrespective if they ride in a horse, a car or anything else. We go over this stuff in trainings. Also recommend the Working Ontologists book. It explains details like that. Regards, Irene Polikoff Executive Partner, TopQuadrant tel: 914-777-0888/ cell: 914-329-8576 www.topquadrant.com -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of donundeen Sent: Friday, October 10, 2008 10:07 AM To: TopBraid Composer Users Subject: [tbc-users] Re: xml and inferencing: adding erroneus types? 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 -~----------~----~----~----~------~----~------~--~---
