Mark; In addition to "magic" properties, I'd suggest taking a look at
functions. This is a step in the same direction (reusable SPARQL
queries). The same general concept. Start by creating a subclass of
spin:Functions. Let's say you name the subclass ":GetCurrentYear".
Then enter the following simple query in the spin:body property:
SELECT ?year
WHERE
{ BIND(year(now()) AS ?year)
}
You can run this query on its own and will find that it returns the
current year - 2012. Now in any SPARQL context for that model, you
can enter the following:
SELECT *
WHERE
{ BIND(:GetCurrentYear() AS ?year)
}
The is will call the body of the aforementioned query. Not much here,
but you can also pass parameters to it as spin:constraints. (You can
also make this a globally defined function for your workspace by
adding a .spin name to register the function - i.e.
myCommonDefs.spin.ttl.) Go back to the previous query and create an
argument by choosing "Create from SPIN Template". Fill in the
predicate with sp:arg1 and set its type to xsd:string.
Now you define the body to take that argument, which is named after
the local name when used in the query - i.e. ?arg1. Let's just create
a string from the above as a kind of "Hello World" example:
SELECT ?year
WHERE
{ BIND(fn:concat(?arg1, year(now())) AS ?year)
}
Now you can pass a value to the function, such as:
SELECT *
WHERE
{ BIND(:GetCurrentYear("The current Year is: ") AS ?year)
}
...and the result is "The current year is: 2012". Of course, you can
do any bit of SPARQL with the function definition - graph patterns,
call other functions, etc. But this is meant as a universally
accessible "Hello World" while exposing some of the less-well-known
data processing elements of SPARQL. The function differs from a magic
property in that it acts as a function call - returns a single value
for each call. And this is usually enough when combined with the
graph pattern matching of SPARQL. Sometimes one needs to return
multiple values, or want a function to act like a triple pattern -
i.e. a virtual or computed property (the term "magic property" is
admittedly an ill-defined way to describe this functionality), and it
is only then that magic properties are needed.
There is much more on this and other SPIN definitions at
http://www.topquadrant.com/products/SPIN.html
-- Scott
On Jun 19, 8:26 pm, Holger Knublauch <[email protected]> wrote:
> On 6/20/2012 10:18, Mark Green wrote:
>
> > Hi,
>
> > I'm having some trouble trying to define a SPIN Magic Property. I can
> > create a new property that is an instance of spin:MagicProperty but
> > when I open the spin:body property to enter the query, it doesn't
> > allow me to enter the query, it instead wants me to choose an
> > instance. Do I have to build the SPIN equivalent of the SPARQL query
> > manually for a Magic Property?
>
> Hi Mark,
>
> use Add empty row to enter a SPIN query for spin:body. This should work.
> (Use Shift-enter for line breaks).
>
> BTW to define a new magic property I don't recommend simply to create an
> instance of spin:MagicProperty. It also should to be a subclass of
> spin:MagicProperties. So the easiest way to achieve that is to open the
> class tree spin:Modules > spin:Functions > spin:MagicProperties, then
> right-click on spin:MagicProperties and create a subclass of that.
>
> Thanks
> Holger
-- 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
