Custom SPARQL Construct with enumeration - sparql

Question

Is it possible to execute SPARQL construct while adding information outside the scope of query? e.g., I want to execute SPARQL construct while defining enumeration information like this:
PREFIX skos:<http://www.w3.org/2004/02/skos/core#>
construct {
?s a skos:Concept
?s ex:index <enumeration starting from 1 -- this is just a sample>
}
where {
?s a skos:Concept
}
is it possible to do something like that with pure SPARQL? what are the alternatives?
* Additional Information *
Probably I am not explained my problem clearly, so basically I want to achieve the following (assuming that ex:index is a valid datatypeProperty):
== Initial RDF triples ==
#prefix skos:<http://www.w3.org/2004/02/skos/core#>
#prefix ex: <http://example.org/> .
ex:abc rdf:type skos:Concept .
ex:def rdf:type skos:Concept .
...
ex:endOfSample rdf:type skos:Concept .
== RDF triples after SPARQL Update execution ==
#prefix skos:<http://www.w3.org/2004/02/skos/core#>
#prefix ex: <http://example.org/> .
ex:abc rdf:type skos:Concept ;
ex:index 1 .
ex:def rdf:type skos:Concept ;
ex:index 2 .
...
ex:endOfSample rdf:type skos:Concept ;
ex:index <endOfSampleNumber> .

Answer 1

You can construct any valid RDF value in a CONSTRUCT. However the query will fail if any of the variables in the CONSTRUCT graph pattern is unbound after executing the WHERE graph. I.e. there can be no binding for ?p in your query and the CONSTRUCT will never execute.
This is an example that should get you started:
PREFIX skos:<http://www.w3.org/2004/02/skos/core#>
PREFIX ex:<http://example.org/construct#>
construct {
ex:someProp a owl:ObjectProperty .
?s ex:someProp (1 2 3)
}
where {
?s a skos:Concept
}
This will result in the construction of seven triples for the property value and the list structure.
The ex:someProp is added because there isn't a good object property in SKOS for ad-hoc lists. It would be best to define the property with some semantic meaning. Also note that while the {ex:someProp a owl:ObjectProperty} triple will be asserted for each match of {?s a skos:Concept}, it is the same triple, hence there will be only one in the end. The price is efficiency, so asserting the property outside of this query would be a better choice - it is included in the above query for the sake of example completeness.