Namespaces in queries, part 3

… in which I backpedal quite a bit, after helpful comments from Laurens Holst on my previous post.

Clarification 1: I don’t think that namespaces are bad. They are good and important. I just think that sometimes you want to ignore them in queries.

Clarification 2: My proposal doesn’t stop anyone from using namespaces and doesn’t change the semantics of any valid SPARQL query. It only makes some currently invalid SPARQL queries valid: those which use the default prefix without declaring it.

Now for the backpedaling: I guess that most people around here see SPARQL as “SQL for triple stores”, something you embed into application code. My perspective on SPARQL has become a bit different recently. Most of my recent SPARQLing was to interrogate SPARQL endpoints with unknown contents, or to explore the open Semantic Web using the SemWebClient library.

I use SPARQL interactively. I write quick one-off queries, see the result right away, and make corrections as needed. Bogus results are noticed and fixed instantly. I rarely re-run a query later on. Number of characters typed matters a lot in this scenario.

Maybe this explains why I advocate such a nutty idea, and my bad for not realizing this earlier.

So, time to shelf this idea until maybe more people will look beyond their own data and play with the open Semantic Web and feel the pain of having to type out the FOAF namespace for the n-th time.

Thanks for all the comments.

This entry was posted in General, Semantic Web. Bookmark the permalink.

4 Responses to Namespaces in queries, part 3

  1. JHendler says:

    We use SPARQL in a lot of ways, incluyding a lot of the sort of interactive thing you are talking about – but that doesn’t make us (MINDSWAPpers) less interested in namespaces – rather it makes us moreso – often we pull things from different sites where a common string (like :name) may be used in different ways than we use it, or someone else does – so when we see foaf:name we don’t want to assume it is the same as doap:name (which might be the name of a project) or random:name which might be some mathematical identity function, etc. etc – if you just want to display things to a user, it may not matter than much, but if you merge these things, you need to be able to control when we want things to merge and when we don’t — some simple OWL is crucial to this, btw – one can express equivalence and difference between these things, allowing for much better control
    JH

  2. Another approach might be to convince endpoint maintainers to pre-define namespaces appropriate to their data. Thus, an endpoint with information about people could maintain default values for the prefixes ‘foaf’ and ‘rel’, while a photograph endpoint might pre-define ‘foaf’, ‘album’, ‘dc’, and ‘dcterms’. You’d still have to type the namespace in the QName, but there’d be no need to explicitly write out the prefix declaration.

  3. Dan Brickley says:

    Better I think to consider this a kind of SPARQL authoring tool. Just as I often write crappy HTML-2-ish text files, then I run “tidy -m asxml index.html” to turn them into XHTML, one might write pseudo-SPARQL and then feed it through a tool to insert extra prefixes etc.

    A bit of perl that reads
    #include ~/stdsparql

    and adds in some extra lines might be useful?

  4. Ora Lassila says:

    Isn’t it great when everyone immediately pounces on you when you innocently post something on your blog. In this case, you have to understand that you were advocating dismantling a mechanism that’s absolutely crucial to the Semantic Web; indeed one might say that a big reason why the Semantic Web was built this way was exactly to get away from name conflicts and any ambiguity about what concepts one is talking about. So no wonder people are up in arms. This is sacred stuff. :-)

Comments are closed.