Mark, Answers below:
As per a couple of previous posts, I am importing some XML using the >>> Semantic XML capabilities of TBC. I am creating an XSD to OWL mapping with >>> the flag to using XSD literal types. I am then modifying one of the >>> properties that is generated as a DatatypeProperty to an >>> InverseFunctionalProperty. When I do this, the XML is imported correctly >>> for the first load but for subsequent loads, it is failing to import the >>> value for this property. >>> >> >> It wouldn't make sense to change DatatypeProperty to >> InverseFunctionalProperty, because InverseFunctionalProperty is a sub >> property of ObjectProperty (you mentioned it as well). This may cause >> inferences to work unexpectedly. >> >> However, it is strange that the XML is imported correctly the first time, >> but failing for subsequent loads. If you want, you can send me a short >> description of what fails and examples offline. >> >> > I think I was a bit misleading here. After going back and looking at the > process I was following, I was first importing the XML and converting to > RDF. Then I was changing the property to an InverseFunctionalProperty and > running against the inference engine. This worked however next time I > imported the XML it would break. Looking at this, I think it is behaving > as I would expect it to. I've now moved past this approach as I realised my > concept is broken. > OK good. > >>> I realise that It doesn't make a lot of sense to set >>> an InverseFunctionalProperty (subPropertyOf ObjectTypeProperty) with a >>> literal however, I am trying to infer sameness across two different >>> datasource on a literal value and I am not sure what else to do? So my >>> questions are, is it the expected behaviour to break the Semantic XML >>> mapping given the scenario I mention in paragraph 1 and if it is, is there >>> another way I can infer sameness using literal values? >>> >> >> Did "spif:cast" function that I mentioned earlier work for you? Trying to >> infer sameness across literals might not be the right direction, because >> literals by themselves don't have an identity. If you have the literal >> "1"^^xsd:integer and "1"^^xsd:string, you cannot have a property like >> owl:sameAs linking them. However, you can infer that they are the same with >> SPIN rules using a function like "spif:cast", where the rules are specified >> on appropriate classes. >> > > Using a literal value as an InverseFunctionalProperty is obviously not > intended given the definition of InverseFunctionalProperty. In practice, > many system store key values as literals and hence I was trying to compare > keys stored as literals rather than simple literal values. I would be > interested to hear any suggested approaches to solving this problem based > on people's experience. The specific problem I have is I have one system > that stores a location value (e.g. 4120) that I need to compare to a field > in another system that has a similar value (e.g. Q-4120). For now I solved > this problem by constructing statements in each system that can be merged > (e.g. <http://mydomain#location-Q-4120>) > I think constructing resources such as <http://mydomain#location-Q-4120> is the right direction. It would make more sense to achieve sameness with owl:sameAs or InverseFunctionalProperty, if the sameness is across resources (or individuals) rather than literals. The literals could be attached as statements on those resources, so they would be easily accessible. Gokhan > > Regards, > Mark. > >> >> Gokhan >> >> >>> >>> Regards, >>> Mark. >>> >>> -- You received this message because you are subscribed to the Google >>> Group "TopBraid Suite Users", the topics of which include Enterprise >>> Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, >>> TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN. >>> To post to this group, send email to >>> topbraid-users@googlegroups.**com <[email protected]> >>> To unsubscribe from this group, send email to >>> topbraid-users+unsubscribe@**googlegroups.com<topbraid-users%[email protected]> >>> For more options, visit this group at >>> http://groups.google.com/**group/topbraid-users?hl=en<http://groups.google.com/group/topbraid-users?hl=en> >> >> >> -- You received this message because you are subscribed to the Google > Group "TopBraid Suite Users", the topics of which include Enterprise > Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, > TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN. > 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-users?hl=en > -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN. 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-users?hl=en
