yes, in general I think I understand and really like the concept of adding type checked properties to classes via instantiated Arguments. My real concern (espcially as a possible SPIN runtime implementer) is not being sure of what the rules are regarding what kinds of resources can be used as the subject of a spin:constraint so that the TBC spin runtime (and by extensions any SPIN adherent runtime) will know how to properly execute the specified constraint? e.g. from what I've seen here there are at least two rules: 1. They can be specified as a sp:Ask or specialized sp:Construct query. 2. They can be specified as an instatiated sp:Argument where the sp:Ask query to be executed by the constraint checker is specified via Argument's spin:body property. Are there more rules that the TBC spin run-time understands? Should these types of rules be parts of the SPIN standard? Just a thought, but perhaps a new 'argument' property would be useful to add to the standard instead of overloading spin:constraint?
________________________________ From: Holger Knublauch [mailto:[email protected]] Sent: Thursday, January 08, 2009 11:39 AM To: [email protected] Subject: Re: ConstructDefaultValues (was: Re: [tbc-users] Re: SPINExamplesandVideos posted) On Jan 8, 2009, at 9:23 AM, Schmitz, Jeffrey A wrote: I think, in general what is throwing me is that the Argument template can be "instantiated" and used as the subject of a constraint, and thus the instantiated argument should (in my mind) be an ASK (or specialized CONSTRUCT) query, not merely contain an ASK query. The comment for spin:constraint says: "The values of this property are "axioms" expressed as CONSTRUCT or ASK queries where the variable" Yes this comment is not precise - it should also mention that SPIN allows to substitute a query with a template of the same type, everywhere. In theory the spl:Argument class could be made a subclass of sp:Ask to clarify this. I will see what I can do to make this clearer for other users - thanks for your feedback! So, anytime I see a spin:constraint property, I would expect it to point directly to either a sp:Ask or (the specialized) sp:Construct query, or a subclass thereof. e.g. the example in the SPIN Modeling Vocabulary doc: ex:Parent a rdfs:Class ; rdfs:label "Parent"^^xsd:string ; rdfs:subClassOf ex:Person ; spin:constraint [ a sp:Ask ; rdfs:comment "must be at least 18 years old"^^xsd:string ; sp:where ([ sp:object sp:_age ; sp:predicate ex:age ; sp:subject spin:_this ] [ a sp:Filter ; sp:expression [ a sp:lt ; sp:arg1 sp:_age ; sp:arg2 18 ] ]) ]. However (for an example where this is not the case) the anonymous, instantiated Argument that is specified as a spin:constraint in the sml:ImportTextFile class is not of class sp:Ask, it merely "contains" an instance of an sp:Ask via its spin:body property. So, I'm thinking your run-time environment must know to look for either possibility to find the Ask query that it needs to execute in order to determine if the current model violates any specified constraints. This also leads to the somewhat confusing concept of the object of a spin:constraint property possibly causing "default value" triples to be constructed, since Arguments not only contain sp:Ask objects but also the concept of setting default values (e.g. the sm:outputVaiable argument of the sml:ImportTextFile class which specifies the default value of "text", and that I'm assuming would be executed by the runtime environment when needed because of the ConstructDefaultValues attached to spin:Modules via the spin:constructor property) The goal of spl:Argument and spl:Attribute is to support a modeling style similar to object-oriented languages. For example in UML you can create attributes and then attach value type, cardinalities and default values - all into a single context. In OWL such declarations (if at all possible) are scattered across multiple definitions such as owl:Restrictions. I believe and hope that the following code shows that such definitions are compact and maintainable: :Parent a rdfs:Class ; rdfs:label "Parent"^^xsd:string ; rdfs:subClassOf :Person ; spin:constraint [ a spl:Attribute ; rdfs:comment "the children of this Parent" ; spl:predicate :child ; spl:minCount 1 ; spl:valueType :Person ] . I guess the confusing aspect here is that the SPL templates do more than constraint checking, but also use the class attachment infrastructure (via spin:constraint) to do more than that, and also define the default values. So the spl:defaultValue is ignored for constraint checking. But that's the same like with other languages: for example properties can have a comment but these are ignored by OWL inference engines. Nobody is forced to use this mechanism of bundling default values and cardinalities, and can define their own modeling vocabulary, e.g. with another dedicated property and object type for such declarations. SPIN can be used to define your own modeling language. Holger --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
