On Sat, 2016-10-01 at 03:10 -0700, neha gupta wrote:
> Paul, thank you.
>
> If I have Student/University ontology and the ontology does not have
> "hasResearch" property can we create like this:
>
> CONSTRUCT {?s ex:hasResearch ?research}
> WHERE {?s rdf:type ex:Student;ex:hasResearch "C-SPARQL"}
>
> to create the property and assign instance to it?
That wouldn't construct any triple because ?research will never be bound
by the WHERE clause. If you ever have a question about what triples will
be constructed, just change the CONSTRUCT {...} to SELECT * and see what
results you get. For every result record, CONSTRUCT will create triples
from the patterns whose variables are bound in the result set.
But now I'm not sure whether you are trying to extend the schema (or
ontology), or just assigning properties to existing subjects.
To add ex:hasResearch into the dataset as an rdf:Property you would just
load some triples like:
ex:hasResearch a rdf:Property;
rdfs:domain ex:Student;
rdfs:range [owl:oneOf ("C-SPARQL" "RIF" "SPIN")].
If you want to do any kind of OWL reasoning over your dataset you would
need to add some more statements to associate ex:hasResearch as a data
property of ex:Student.
On the other hand, if you just want to say that all students who are
taking a course called "Intro to SPARQL" will "have
research"="C-SPARQL", that would be like:
CONSTRUCT {?s ex:hasResearch "C-SPARQL"}
WHERE {?s rdf:type ex:Student; ex:hasCourse/rdfs:label "Intro to
SPARQL"}
Regards,
--Paul
>
> On Fri, Sep 30, 2016 at 8:52 PM, Paul Tyson <phty...@sbcglobal.net> wrote:
>
> > On Thu, 2016-09-29 at 13:44 -0700, tina sani wrote:
> > > I want to know about the Construct query.
> > > How it differs from Select query
> >
> > One way to think about it, if you have any background in relational
> > databases, is that SELECT returns a highly denormalized table (at least,
> > from any non-trivial query). On the other hand, CONSTRUCT will give you
> > an over-normalized set of tables, if you think of each RDF property
> > triple (or quad, if you include graph uri) as an RDBMS table.
> >
> > That is a very abstract view. Syntactically, the results of CONSTRUCT
> > and SELECT are quite different. SELECT must be serialized into something
> > like a table model (csv or the isomorphic xml, json, or text versions).
> > CONSTRUCT results are serialized into some RDF format.
> >
> > > Is it create a new property/class which is not already in the ontology or
> > > it just creates new triples.
> >
> > You can do either (or both). You can use CONSTRUCT to extract a
> > subgraph, or to create new triples based on some rules about the
> > existing data.
> >
> > > I will appreciate if some one come with a simple example. I have searched
> > > web, but could not grasp it.
> >
> > Extract a subgraph. Just get rdf:type and rdfs:label of all subjects.
> > CONSTRUCT {?s rdf:type ?type;rdfs:label ?label}
> > WHERE {?s rdf:type ?type;rdfs:label ?label}
> >
> > Make a new statement based on certain conditions in the dataset.
> > CONSTRUCT {?s :new-property false}
> > WHERE {?s rdf:type ex:TypeA;ex:property1 "A"}
> >
> > Materialize superclass properties:
> > CONSTRUCT {?s rdf:type ?super}
> > WHERE {?s rdf:type ?type;?type rdfs:subClassOf* ?super}
> >
> > As another responder mentioned, CONSTRUCT just returns the triples--it
> > does not modify the dataset. Use a SPARQL update statement
> > (INSERT/WHERE) for that. I've found that with complex or large results
> > it is better in jena to do a CONSTRUCT query and then load the triples
> > into the TDB repository, rather than do an INSERT/WHERE update, which
> > can exhaust resources if the resulting graph is large.
> >
> > Hope this helps.
> >
> > Regards,
> > --Paul
> >
> >
