W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > May 2005

RE: Uniprot RDF in RDF Gateway

From: Geoff Chappell <gchappell@intellidimension.com>
Date: Fri, 13 May 2005 08:40:38 -0400
To: "'Eric Jain'" <Eric.Jain@isb-sib.ch>
Cc: <public-semweb-lifesci@w3.org>
Message-ID: <007901c557b8$f84270f0$6401a8c0@gsclaptop>

> -----Original Message-----
> From: Eric Jain [mailto:Eric.Jain@isb-sib.ch]
> Sent: Friday, May 13, 2005 3:00 AM
> To: Geoff Chappell
> Cc: public-semweb-lifesci@w3.org
> Subject: Re: Uniprot RDF in RDF Gateway
> Geoff Chappell wrote:
> > Will do. In the meantime, you're welcome to pass any queries along to me
> and
> > I'll add them as examples.
> So here's another query:
>    select
>      ?protein ?go
>    using
>      uniprot
>    where
>      { $protein [rdf:type] Protein } and
>      { $protein classifiedAs $go }

I'll try to get this and the others up there today.
> Can you set a default namespace?

Sort of... you can specify a baseURI (session.baseURI), but it doesn't work
by just simple concatenation (like namespaces) so can't handle urns (since
it doesn't understand the opaque part of the urn uri.) 
> If you allow restrictions on namespaces, you could also add:
>    and namespace($go) = 'urn:lsid:uniprot.org:go:'

We have a function - uripart - that can break apart uris into their
component parts, but again urns are mostly opaque to it. I can just use a
string function instead (instr, regexp, ...)
> Incidently, what's the overhead of federated queries? Let's say the GO
> data
> was stored in its own database (on the same server), how much would this
> slow down the query above?

Depends a bit on what you're federating.... for database tables, it's pretty
linear wrt to the number of federated sources. If you're federating external
sources of data via dataservice connections, it can vary considerably (since
dataservice jobs can occur in parallel and often dataservices are
schema-aware and so can disregard certain triple patterns). 

Received on Friday, 13 May 2005 13:01:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:23 UTC