Thanks for clarifying that; I need to read up more on some of these ontological concepts.
However, I think that was a bad example, and strayed from my orginal point, which is that there should have been two properties created to begin with, with different domains: marc:tag-controlfield domain marc:controlfield AND marc:tag-datafield domain marc:datafield then none of these inferencing issues would matter On Oct 10, 1:42 pm, "Irene Polikoff" <[EMAIL PROTECTED]> wrote: > 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-8576www.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 -~----------~----~----~----~------~----~------~--~---
