Hey Holger, by inspecting SPINConstructors, I have noticed that constructors (and probably constraints as well?) are "inherited" by walking up the subclass chain and looking for them. Am I right?
I had a similar use case implemented as custom Jena rules. Properties can be inferred by constructing OntModelSpec with GenericRuleReasoner which parses the rules. They could look something like that: [constructors: (?class rdf:type rdfs:Class), (?class <http://spinrdf.org/spin#constructor> ?o), (?subClass rdfs:subClassOf ?class), noValue(?subClass <http://spinrdf.org/spin#constructor>) -> (?subClass <http://spinrdf.org/spin#constructor> ?o) ] [constraints: (?class rdf:type rdfs:Class), (?class <http://spinrdf.org/spin#constraint> ?o), (?subClass rdfs:subClassOf ?class), noValue(?subClass <http://spinrdf.org/spin#constraint>) -> (?subClass <http://spinrdf.org/spin#constraint> ?o) ] I think that would be a cleaner approach and a better reuse of Jena's machinery. Would that work for SPIN API? Martynas graphityhq.com -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected] --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
