Comments on: Namespaces in queries, part 2 http://dowhatimean.net/2006/10/namespaces-in-queries-part-2 Richard Cyganiak's Weblog Thu, 09 Sep 2010 20:45:09 +0000 http://wordpress.org/?v=2.6.3 By: Richard Cyganiak http://dowhatimean.net/2006/10/namespaces-in-queries-part-2#comment-12614 Richard Cyganiak Thu, 26 Oct 2006 16:08:11 +0000 http://dowhatimean.net/2006/10/namespaces-in-queries-part-2#comment-12614 <p>Laurens: Yes, RDF uses full URIs, but there is a clear convention for separating URIs into namespace and localname: Everything up to the last non-NCName character goes into the namespace. Sesame, for example, stores URIs internally as namespace/localname pairs.</p> <p>You say that a change in the data might break the query result. That's a good point. This would cause problem for queries that will be re-executed multiple times over a longer period of time, so for that kind of query it's certainly safer to use explicit namespaces.</p> <p>But it would not cause problems for the kind of queries I'm interested in: one-off, interactive queries. For these, number of characters typed matters much more, and if the results are wrong then the user can correct the query right away.</p> <p>So I guess my suggestion only makes sense in this particular context. Thanks for your help in clarifying this.</p> Laurens: Yes, RDF uses full URIs, but there is a clear convention for separating URIs into namespace and localname: Everything up to the last non-NCName character goes into the namespace. Sesame, for example, stores URIs internally as namespace/localname pairs.

You say that a change in the data might break the query result. That’s a good point. This would cause problem for queries that will be re-executed multiple times over a longer period of time, so for that kind of query it’s certainly safer to use explicit namespaces.

But it would not cause problems for the kind of queries I’m interested in: one-off, interactive queries. For these, number of characters typed matters much more, and if the results are wrong then the user can correct the query right away.

So I guess my suggestion only makes sense in this particular context. Thanks for your help in clarifying this.

]]> By: Laurens Holst http://dowhatimean.net/2006/10/namespaces-in-queries-part-2#comment-12613 Laurens Holst Thu, 26 Oct 2006 15:34:33 +0000 http://dowhatimean.net/2006/10/namespaces-in-queries-part-2#comment-12613 <p>Also, I don’t really see how this would work, given that RDF is using full (concatenated) URIs, not namespace/key pairs. A substring match on the last part of the string? Then ‘me’ would also match ‘name’, ‘name’ would also match ‘fullname’, etc.</p> <p>~Grauw</p> Also, I don’t really see how this would work, given that RDF is using full (concatenated) URIs, not namespace/key pairs. A substring match on the last part of the string? Then ‘me’ would also match ‘name’, ‘name’ would also match ‘fullname’, etc.

~Grauw

]]> By: Laurens Holst http://dowhatimean.net/2006/10/namespaces-in-queries-part-2#comment-12612 Laurens Holst Thu, 26 Oct 2006 15:31:28 +0000 http://dowhatimean.net/2006/10/namespaces-in-queries-part-2#comment-12612 <p>I think that the main risk is that you are depending on current content of the store conforming to some constraints. If at some point the store is expanded in some other part of the software that uses the same store (e.g. a fathers:name property is added), then it will suddenly start to get buggy. After all, in good modular programming models, a change in one module of a software should not require a change in another. And these bugs will be difficult to hunt down, because no changes were made to that relevant part of the software.</p> <p>Also, testing methods would be much more complex. With this, you would basically need to query the entire store and check the results just to make sure that in all cases there is no naming conflict, whereas if you’re using namespaces (and the store integrity is dependable) there can never be a conflict. Also, you would need to repeat this check for everything that adds new properties to the database.</p> <p>So it doesn’t seem like a very good idea. And those namespaces are copy/paste anyway, right. I mean, as a programmer there are more tedious tasks than just that (debugging for example :)).</p> <p>~Grauw</p> I think that the main risk is that you are depending on current content of the store conforming to some constraints. If at some point the store is expanded in some other part of the software that uses the same store (e.g. a fathers:name property is added), then it will suddenly start to get buggy. After all, in good modular programming models, a change in one module of a software should not require a change in another. And these bugs will be difficult to hunt down, because no changes were made to that relevant part of the software.

Also, testing methods would be much more complex. With this, you would basically need to query the entire store and check the results just to make sure that in all cases there is no naming conflict, whereas if you’re using namespaces (and the store integrity is dependable) there can never be a conflict. Also, you would need to repeat this check for everything that adds new properties to the database.

So it doesn’t seem like a very good idea. And those namespaces are copy/paste anyway, right. I mean, as a programmer there are more tedious tasks than just that (debugging for example :)).

~Grauw

]]>