SparqlPress is a project. Primary ingredients are WordPress and SPARQL. It is work in progress.
The goal for SparqlPress is easy-to-use, low-barrier-of-entry, access to the linked data web.
It is based on general thoughts around WordPress, FOAF, SPARQL and specific visions such as danbri's slides from SPARQLing Days.
There is partial overlap with the efforts by DiSo.
There are two, intimately-related sides to the idea: producing data, and consuming it. Another goal is to make it easy for Wordpress to expose more data in SPARQL-friendly form. Another is to make it easier to use a Wordpress installation as a personal, perhaps even private, local aggregation of such data. This could include information crawled from the blogs and social network profiles of friends, family and colleagues, alongside other data that's not necessarily available in the public Web.
Some related notes from foaf-dev:
Saying things in the public Web is always complex and prone to gaming, schoolyard ego dynamics, and awkwardness. We found this in the first version of FOAF. In FOAF originally, we allowed people to say "knows", "knowsWell", or "friend". Even this limited ability created early awkwardness: it was enough to say, in effect, "I know this person well but they're not a friend". Which isn't what everyone likes to hear about themselves. Similarly in XFN, person A might consider B an "acquaintance", while B might consider A a "friend". Saying these things in a public (aggregatable, queryable) form is, again, sometimes a bit awkward.
But safe within the privacy of your own database, you might be a little more explicit in the way you classify your contacts.... We'll have local aggregations of RDF from blogs, FOAF, converted XFN etc., then merge in some private data (eg. people you've met at conferences, addressbooks, family tree data, private XFN claims). Then we can apply foaf:Group definitions to provide custom views into the offerings of things like Twitter and Flickr, where people are currently feeling overwhelmed due to the difficulty of providing more filtered, nuanced views of the activity streams of their 100s of "friends".
SparqlPress will (at least for now) be implemented as a WordPress plugin written in PHP, with most of the core functionality separated into standalone components for easy reuse on other PHP platforms.
The components are separated into four broad categories.
This is the category with prerequisites for data, essentially creating a part of the linked data web, for internal and external use. Components in this category generally "just work" and require no user interaction.
- FOAF/SIOC/SKOS (people, posts, categories and tags), based on:
- OpenID+FOAF, based on:
- see also F2FPlugin, which exports lists of comment-approved openids
This is the "middleware" category. Stuff here doesn't create or consume triples, but rather provides what's necessary for the other components to work and communicate. Under normal circumstances, no user interaction should be necessary, but some administration tasks should be possible (setup, initial configuration, typical database maintenance).
- Database, based on:
- ARC by bengee
- ARC should not be bundled, but offered as a separate download. With proper symlinks or PHP include_path settings it should be fine even when installed elsewhere.
- ARC by bengee
- Configuration interface, based on:
- ARC's rdf-tool WP extension by bengee
- Scutter, based on:
- mortenf's "unpublished" WP/ARC stuff
Perhaps the scutter should be an ARC plugin? mortenf 06:57, 17 January 2008 (PST)
This is the category where the local part of the linked data web is linked to the rest of the world. Components in this category generally have a user interface in the WordPress administration interface.
- Import of local exports (!)
- Friend-linkage maintenance
- Category-linkage maintenance, possibly also using MOAT
- External data (other profiles, e.g. flickr export etc.)
- Querying (custom CONSTRUCT-queries against (other) SPARQL endpoints)
This category could perhaps be covered by a basic pluggable plugin, with hooks for extensions via other simple plugins (one for each item in the list), or even via RDF... The remaining functionality would then be covered by the scutter. mortenf 06:57, 17 January 2008 (PST)
This is the fun category, where data becomes visible and usable. This is for the most part accessible from the outside.
- An expandable widget with FOAFNaut (or HTMLNaut) by JibberJim?
- Public SPARQL, based on:
- Auto-linkage everywhere for "related" people, categories, etc.
- Category-suggestions and -usage when writing posts (based on friends' use)
SPARQL Endpoint Discovery
There have been some early experiments, e.g. SADDLE, or SparqlEndpointDescription on the esw wiki which seem discontinued. More recently, the Sindice team seems to be working on a SemWeb Crawling Ontology, the spec itself 404s, though.
In general, a good solution to the endpoint discovery issue could be to follow the DCMI guidelines, so that we get DC, GRDDL, and eRDF friendliness out of the box, i.e.:
<link rel="schema.ex" href="http://example.com/ns#" /> <link rel="ex.sparql-endpoint" href="/rdf-tools/sparql" />
Now, is there an existing property we could re-use, or do we have to create one? The Sindice prop seems like a good candidate, but its domain is "Dataset" whereas it would be nice to have a property that could be associated with any type of resource (e.g. Persons, too). Once we've agreed on a property, the html tags could be auto-added by the RDF Tools Plugin.
The WordPress administration interface should provide access for administrator to a single low-level configuration screen (storage parameters etc.), and for all users to a number of screens for linked data configuration etc. where necessary (some tasks are probably better integrated on e.g. the category handling screen).
Administrator Level Page
A new page under "Options", titled "SparqlPress" (possibly with pluggable sections), inspired by ARC's rdf-tool WP extension:
- Store/database options (should perhaps also include table prefix, more?)
- Scutter configuration (timeout values etc.)
- Endpoint access configuration (perhaps also a similar section per user, for stricter user access configuration?)
User Level Pages
- An overview page with a mini-feed with new "stuff" from friends.
- A page for maintaining external data, e.g. friends' links, other profiles, SPARQL queries against other (friends') endpoints etc.
- Concept linking, to link own categories with friends' and MOAT?
The storage component should create a global object for other components to use, $SparqlPress (an ARC2::Store?), with methods that simplify "plugin" development, e.g. $SparqlPress->query().
A scutter that use the ScutterVocab could expose the following methods:
- addGraph($iri, $origin=current_wordpress_user): Register a graph, queue for later fetching, recording origin as either current user (for a graph added manually) or a IRI (for a graph discovered via rdfs:seeAlso etc.)
- skipGraph($iri, $reason): Mark a previously registered graph as (to be) skipped, for a specific (text) reason
- removeGraph($iri): Unregister (and delete) a previously registered graph, including stored scutter information and graph contents
- go($count=1): Try to fetch (possibly updating) next graph(s) in queue, recording outcome and possibly looking for rdfs:seeAlso etc.)
Use of this API of course implies that the scutter won't care about data added directly via SPARQL+ LOAD etc...
Scutter information about graphs should be stored in (a) separate graph(s), how to name? mortenf 07:14, 23 January 2008 (PST)
- URIs for people
- Support for multi-author blogs (or should single user be assumed)?
- Endpoint autodiscovery
- Licensing (see below)
- Initial spec'ing
- Basic storage and platform
- This probably needs a "separate" named graph in the storem, everything else will have a definitive source URI.
SparqlPress is developed in a distributed manner, with interested parties maintaining Bazaar repositories synced on a semiregular basis.
- Spoogle, by mortenf
bzr whoami "Joe Triple <firstname.lastname@example.org>" cd /path/to/public/root/webfolder/ bzr get http://bzr.mfd-consult.dk/sparqlpress/
Assuming your webroot is /path/to/public/root/, and Apaches's mod_index is active, you should now be able to browse the code at http://example.com/webfolder/sparqlpress/.
Later, when you want to update your branch with changes from the original branch, try:
If you want to update with changes from another branch (not the original) instead, try:
bzr pull http://other-branch.example.com/
Those might not work, depending on what changes have been committed on the different branches. Then try the following instead:
bzr merge http://other-branch.example.com/
And finally, after merging or making local changes:
bzr commit -m "Message about what has changed..."
Some other helpful commands:
bzr status bzr log bzr add bzr diff bzr help
Don't forget to list your repository branch above, and if possible please also install bzr-feed so it can be included in the global feed for SparqlPress development update notification.
Seems W3C license could be a good choice, as ARC is already using that? mortenf 06:57, 17 January 2008 (PST)
There might be a problem including FOAFNaut or HTMLNaut, as the licensing isn't clear mortenf 04:35, 23 January 2008 (PST)
You can probably ask questions in #foaf on irc.freenode.net.
Preliminary agenda suggestion:
- Bazaar usage
- Architecture and development
A ScheduledTopicChat was held in #foaf on 2008-01-16.
- danbri: Contact R2D2 team about WordPress as well as d2rq and all other 4-letter teams with numbers...
- ✓ mortenf: Create initial Bazaar repository
- ✓ mortenf: Wiki-writeup of ideas/plans
- ✓ mortenf: Mail about above and Bazaar instructions
- ✓ bengee: Do something about SPARQL endpoint autodiscovery (next action: pick/create a prop)