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
-~----------~----~----~----~------~----~------~--~---

Reply via email to