cygri’s notes on web data

Continuing a thread about views in triple stores.

Leigh Dodds pointed out the need for something like SQL’s views in RDF stores, and suggested vocabulary namespaces as a partitioning mechanism:

The […] subset may be created by filtering out the classes and properties extracted from the database based on their namespaces. For example I might have a triple store containing a mixture of public/private data, with the latter in a separate namespace and I want to pull out just the public aspects for returning from a web service.

I replied, somewhat off-hand:

I think this is not such a good idea. Namespaces are just that, namespaces. Don’t overload them with access control.

Leigh disagrees:

I’m not sure how he’s using the term “access control” here, that’s not what I was suggesting. And namespaces are intended to partition vocabularies, so not using them as a way to ignore data that’s not of interest seems bizarre to me.

First, Leigh, I do agree with you about the worth of views, especially to protect applications from schema changes.

Yes, namespaces are for partitioning vocabularies. But along what kind of boundaries? I think that the best boundaries are semantic. Classes and properties about persons go into one vocabulary. Classes and properties about computer software into another.

Your suggestion is to use your application’s publishing policy as a boundary. Stuff intended for public use goes into one vocabulary, the private backend data into another.

As long as this distinction somewhat coincides with a semantic boundary, I can see no fault with this approach. But otherwise, there are a number of downsides:

• Changing your publishing policy gets harder. If you decide to make some formerly private data public, you have to move properties between vocabularies, a rather expensive move.
• Having more than two views, with some overlap, becomes difficult.
• You reduce the reusability of your vocabulary. Other parties might want to re-use your terms, but not your publishing policy.

In SQL, views can be created, changed and removed without affecting the underlying database schema and data. That’s their whole point. With the namespace-as-view approach, changing a view means changing the schema (vocab term URIs) and the data (triples using the term).

Of course, I don’t know anything about the use case that prompted Leigh’s original post, and everything I say might or might not apply to the specific circumstances. I’m just voicing general design opinion here. So as long as it gets the job done …

The Folksonomy meme has been bouncing around the blogosphere for a couple of weeks. The idea is to categorize information (such as bookmarks or photos) by user-defined keywords, often called tags. This is especially powerful when combined with a social/collaborative component, such as in the popular web apps del.ici.ous and Flickr.

The old-school alternatives are the taxonomy and the controlled vocabulary. Here, an analyst will examine the information space and come up with good categories. Changing the categories later is not possible or expensive. Examples are the Yahoo! directory and anything ever done in the library sciences.

Folksonomies are messy, emergent, bottom-up, cheap and conceptually simple. Taxonomies are clean, well-designed, top-down, expensive and conceptually complex.

I hazard a guess that most of the Semantic Web crowd is, like me, firmly in the ”˜well-designed metadata’ camp. Our vocabularies and ontologies are designed by experts, then handed down to the users. We are not at ease with the idea of users creating their own categorization schemes. If we’ve learned anything from experience, then that the average user is unable to get a subclass realtionship right. A bunch of sloppily assigned tags will not be useful for inferencing.

Clay shirky has something to say (via BoingBoing):

This is something the ‘well-designed metadata’ crowd has never understood — just because it’s better to have well-designed metadata along one axis does not mean that it is better along all axes, and the axis of cost, in particular, will trump any other advantage as it grows larger. And the cost of tagging large systems rigorously is crippling, so fantasies of using controlled metadata in environments like Flickr are really fantasies of users suddenly deciding to become disciples of information architecture. …

Any comparison of the advantages of folksonomies vs. other, more rigorous forms of categorization that doesn’t consider the cost to create, maintain, use and enforce the added rigor will miss the actual factors affecting the spread of folksonomies. Where the internet is concerned, betting against ease of use, conceptual simplicity, and maximal user participation, has always been a bad idea.

He’s right.

Betting on the Semantic Web is betting against ease of use, conceptual simplicity, and maximal user participation. And I don’t see how ontologies and the RDF data model stand even the slightest chance in this particular area.

This is something we’ll have to find an answer to.

Leigh Dodds wants views in triple stores:

Views are an important feature of relational databases, providing a way to abstract over complex queries, subset data to just the minium required for a given task, as well as providing a point around which a schema can be refactored without having to (immediately) change the applications that use it.

Leigh proposes two approaches:

The first is to apply a “window” on the graph, and only extract the data that’s within a certain distance of my origin.

This is implemented easily, but doesn’t work well. If you need a query depth of 3 or 4 (which is likely), you will pull in lots of stuff that you don’t need.

The second subset may be created by filtering out the classes and properties extracted from the database based on their namespaces. For example I might have a triple store containing a mixture of public/private data, with the latter in a separate namespace and I want to pull out just the public aspects for returning from a web service.

I think this is not such a good idea. Namespaces are just that, namespaces. Don’t overload them with access control. This scheme also doesn’t work if you want to filter by data (e.g. by publication date) instead of by schema.

I think that SPARQL’s proposed CONSTRUCT feature could do a nice job here. Basically, it’s like an RDQL query. But instead of returning a “result table”, the results will be stuffed into an additional set of graph patterns to form a new RDF graph. This constructed graph can have a structure very different from the original data, and can use different vocabulary. Very simple example:

CONSTRUCT   ( ?x foaf:name ?name )
WHERE       ( ?x vcard:FN ?name )

For the refactoring scenario, you would change the query pattern, but leave the construct pattern unchanged.

CONSTRUCT, SOURCE and optional patterns are the SPARQL features I’m looking forward to the most.

Phil Dawes suggests to deprecate RDF/XML. His plan for action:

• Deprecate RDF/XML as the default serialisation of RDF. Make it clear that it is tricky to write by hand (i.e. by putting this note in the W3C literature), and that if people want human-oriented xml interchange, they should use xml.
• Develop tools to make it easy to specify a mapping between an xml dialect and RDF triples. For important web xml protocols (atom, rss2) specify some default xml to rdf triple mappings.
• Promote turtle/n3 as the default human-oriented syntax
• Reposition RDF as an information integration and knowledge management technology. It really excels at this, more so than any competing technologies (IMHO).
• Promote one of the other triple-based xml serialisations for embedding rdf directly in XML documents. (e.g. trix or rxr)

I couldn’t agree more. RDF/XML’s goal was to be just like XML with a few rdf:this and rdf:that sprinkled in. In retrospect, it’s obvious that this idea was misguided. RDF/XML is bloated, causes unnecessary confustion and clouds the real point of RDF (the data model, not the serialization).

RDF won’t catch on before RDF/XML is either completely hidden behind widespread APIs, or there’s a practical alternative to RDF/XML in widespread use. Such as TriX, which is my favourite alternative, if only by association with its developers.