Having said this, OWL also uses rdfs:subClassOf for the
restrictions, and not an owl:restriction property...
I guess the difference here may be that a restriction is still just
defining an (anonymous) class and nothing more. An Argument on the
other hand is not only defining a 'constraint' on a property, but also a
default value for that property, two fairly disjoint concepts.
1) They can be specified as ASK or CONSTRUCT queries
2) They can be specified as template instances where the body of
the template must be an ASK or CONSTRUCT query.
I might suggest that these rules be added to the SPIN vocabulary
document, unless they exist elsewhere already, with perhaps an example
of using an instantiated Argument for a constraint.
A confusing aspect here is that, similar to RDF Schema and OWL,
SPIN uses itself as its metalanguage. So templates use spl:Arguments to
define their arguments which are then used at run time. All a bit
meta-meta, but fortunately only the implementors of the engine need to
really understand those details :)
Yes, I noticed that. I haven't taken the time yet to fully digest all
the implications.
Anyway, thanks for the discussion, it has certainly served my main
purpose of helping me develop a deeper understanding of the concepts in
SPIN.
Best Regards,
Jeff
________________________________
From: Holger Knublauch [mailto:[email protected]]
Sent: Thursday, January 08, 2009 12:28 PM
To: [email protected]
Subject: Re: ConstructDefaultValues (was: Re: [tbc-users]
Re:SPINExamplesandVideos posted)
On Jan 8, 2009, at 10:15 AM, Schmitz, Jeffrey A wrote:
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.
spl:Argument and Attribute are just examples of the more general concept
of SPIN templates. The rules of the runtime are simpler:
1) They can be specified as ASK or CONSTRUCT queries
2) They can be specified as template instances where the body of the
template must be an ASK or CONSTRUCT query.
In general, just iterate over all values of spin:constraint.
a) if it's a template instance then substitute it with the body,
pre-binding the arguments of the template
b) execute the query (which by now is an ASK or a CONSTRUCT query)
A confusing aspect here is that, similar to RDF Schema and OWL, SPIN
uses itself as its metalanguage. So templates use spl:Arguments to
define their arguments which are then used at run time. All a bit
meta-meta, but fortunately only the implementors of the engine need to
really understand those details :)
Just a thought, but perhaps a new 'argument' property would be useful to
add to the standard instead of overloading spin:constraint?
Yes I thought about this as well - this could be made a sub-property of
spin:constraint to make sure that the constraint mechanism will still
execute them. Right now I'd prefer to keep the language smaller but if
more people find the same need then such a property could be introduced.
Having said this, OWL also uses rdfs:subClassOf for the restrictions,
and not an owl:restriction property...
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
-~----------~----~----~----~------~----~------~--~---
