In the past, I've mostly used RAP (RDF API for PHP) to set up a triplestore in a MYSQL database. It includes scripts that do all the setup--following the example has it up and running in less than 5 or 10 minutes. RAP also includes classes for doing the sparql queries. Basically, you create what RAP calls a MemModel (basically, an RDF graph in memory), write the SPARQL query string. So to make a subgraph of univ:CourseInstances with type and their titles:

$queryString = "
PREFIX rdf <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX dc <http://purl.org/dc/elements/1.1/>
PREFIX univ <http://www.ravendesk.org/univ-ont#>


CONSTRUCT {
?courseinst rdf:type univ:CourseInstance .
?courseinst dc:title ?title
}


WHERE {
?courseinst rdf:type univ:CourseInstance .
?courseinst dc:title ?title
}
";


$result = $model->query($queryString);

Then do what you will with the result. RAPs documentation here walks you through it.

I've also started to use the ARC2 PHP classes. SPARQLing with it works similarly, though I think so far it only supports querying against a store (i.e., not against an in-memory graph).

$result = $store->query($queryString);


See this for examples.

ARC2 is nice for being lighter weight, so less likely to hit memory problems, and if you are doing AJAXy things it serializes graphs to JSON for you.

On the abstraction question--sorry to say I can't offer much advice, having never used D2RQ or D2R. Since I don't have direct access to the database, I've just been scraping the data from the web page listing all the courses and info using SIMILE's Solvent, then pouring that data into either the RAP or the ARC2 store and running from there. If it is okay for your data to be a little out-of-date (depending on how often you re-scrape the page), this might be more straightforward. It's possible that our schools will be spitting out similar web pages, so if you email me at pgosetti-at-umw.edu I'll email you the script to see if it'll be helpful to use as a starting point.

And thanks for the info about attributes you'll use! That's exactly the kind of thing I'm curious about in how people might use this -- especially the waitCap and maxEnrol. In the latest version, I've split about univ:meetTime into univ:meetStart and univ:meetEnd -- you might be able to use those to derive the morning/afternoon/evening info if it is not explicit in your source data. Last note, and this might be crucial--our school also lists by CRN #'s. When I checked with our database people, it turned out that our CRNs are unique _within_ a semester, but not overall. That is, they're no good for creating unique URIs for different univ:CourseInstances (unless your model will be restricted to only one semester).

Good luck!
Patrick