Extending DataSource to retrieve DataSources based on a urlPattern
Christian Brenninkmeijer
I would like to propose an addition to the DataSource Class.
There is currently a method
public Builder urlPattern (String urlPattern)
But no effective way of discovering which DataSource has a particular
urlPattern
Currentrly you would have to do
Set<DataSource> getDataSources()
for each Datasource
public String getUrl(String id)
I would like to propose the addition of a method:
public static DataSource getByURLPattern(String urlPattern) {
Which attempts to find a DataSource with this urlPattern or if none is
found creates one.
The current implementation use the whole prefix (including the
http://www) as both the sysCode and the name for the new DataSource.
I use a mapping from prefix (only) to DataSource
And an Set of DataSources for those that have both a Prefix and a Postfix.
This will add some extra memory requirements to implementations that
have many DataSources which have urls.
===
I would also like to propose a few semantic sugar methods.
All these methods operate over the same internal data as the urlPattern
methods.
public Builder nameSpace(String nameSpace){
Same effect as: Builder urlPattern (nameSpace + "$id")
public static DataSource getByNameSpace(String nameSpace){
Same as effect as: DataSource getByURLPattern(nameSpace + "$id")
The nameSpace methods are proposed as they avoid having to add "$id" one
one side to only have to strip it out on the other end.
Plus possibly:
public static DataSource getByURL(String url)
Similar effect to: getByURLPattern(String urlPattern) but has to do
some guessing of which part is the id.
The getByURL method is more for the case where the URL has a postfix
which we currently do not have with OpenPhacts
Please send me samples of your urls with postfixes so I can make sure
they are covered correctly.
Removal of the getByURL method would make the getByURLPattern slightly
more efficient.
I have implemented this including testing at:
https://github.com/openphacts/BridgeDb/tree/Christian_getByURL
No package or class has been added to the imports.
--
Christian Brenninkmeijer
Department of Computer Science
University of Manchester
Egon Willighagen
<Bren...@cs.man.ac.uk> wrote:
> I would like to propose an addition to the DataSource Class.
Related to this, I had a first go at the DataCollection idea... I had
hoped to rebase my patches on the latest master, but did not get
around to it...
Please find the initial results:
https://github.com/egonw/BridgeDb/commits/8-datacoll
So, no merging please... just to give an idea. Comments most welcome
of course...
My first one: I am not using the right URI class :)
Egon
--
Dr E.L. Willighagen
Postdoctoral Researcher
Department of Bioinformatics - BiGCaT
Maastricht University (http://www.bigcat.unimaas.nl/)
Homepage: http://egonw.github.com/
LinkedIn: http://se.linkedin.com/in/egonw
Blog: http://chem-bla-ics.blogspot.com/
PubList: http://www.citeulike.org/user/egonw/tag/papers
Christian brenninkmeijer
urlPattern (New thread for new Topic)
Hi Egon,
I had a first look at the DataCollection object you created.
I see that you are giving each DataCollection a URI identifier so that
it can be referred to.
I am not sure it is correct to give a URI identifier to a DataCollection
it is after all not done for other BridgeDB object.
Another approach is to assign the URI identifiers at the Webservice level.
As these are really only required if the information is exported out of
the System.
However if you do want to go down the route of giving it a URI identifer
(at construction time) than the Object once created MUST be inmutable.
So either all the parameters have to be loaded in the constructor(s) and
all set methods removed or
the URI identifier has to be compute and changed as the Object changes.
As for the "right" URI class.
While we use the org.openrdf for reading in Data I still think the
java.net is the right class to use in the package org.bridgedb;
The reason for this is the expressed desire of the BirdgeDB team to keep
this core package as light wieght as possible.
The java.net gives the advantage over String of having proper parsing
and type checking.
The useful functionality from org.openrdf.URI of spliting between
NameSpace and LocalName can easily be added with a few lines of code.
I really like the idea that a DataCollection has an identifierPattern.
This reinforces the idea that the main purpose of a DataColection is to
map to Xrefs with different DataSoucres but the same id without having
to explicitly add the mapping.
However I struggle to understand what the "namespace" variable is
intended for.
On 05/03/2012 20:47, Egon Willighagen wrote:
> Related to this, I had a first go at the DataCollection idea... I had
> hoped to rebase my patches on the latest master, but did not get
> around to it...
>
> Please find the initial results:
> https://github.com/egonw/BridgeDb/commits/8-datacoll
>
> So, no merging please... just to give an idea. Comments most welcome
> of course...
>
> My first one: I am not using the right URI class :)
>
> Egon
>
--
Christian Brenninkmeijer
University of Manchester
MyGrid team
Egon Willighagen
thanx for your feedback!
On Tue, Mar 6, 2012 at 10:30 AM, Christian brenninkmeijer
<"Christian"@mygrid.org.uk> wrote:
> I see that you are giving each DataCollection a URI identifier so that it
> can be referred to.
> I am not sure it is correct to give a URI identifier to a DataCollection it
> is after all not done for other BridgeDB object.
This is following identifiers.org:
http://identifiers.org/examples#data_collection_uri
> However if you do want to go down the route of giving it a URI identifer (at
> construction time) than the Object once created MUST be inmutable.
I considered that and only did not do it yet because it was more
work... it would make it like DataSource.
Martijn, if you prefer it with a singleton design too, I'll make it so.
> So either all the parameters have to be loaded in the constructor(s) and all
> set methods removed or
> the URI identifier has to be compute and changed as the Object changes.
I would probably adopt the builder design already used by DataSource.
> As for the "right" URI class.
> While we use the org.openrdf for reading in Data I still think the java.net
> is the right class to use in the package org.bridgedb;
> The reason for this is the expressed desire of the BirdgeDB team to keep
> this core package as light wieght as possible.
> The java.net gives the advantage over String of having proper parsing and
> type checking.
> The useful functionality from org.openrdf.URI of spliting between NameSpace
> and LocalName can easily be added with a few lines of code.
OK, I'll keep using that then.
> I really like the idea that a DataCollection has an identifierPattern. This
> reinforces the idea that the main purpose of a DataColection is to map to
> Xrefs with different DataSoucres but the same id without having to
> explicitly add the mapping.
Indeed... standing on the shoulders of identifiers.org.
> However I struggle to understand what the "namespace" variable is intended
> for.
The namespace returns in the MIRIAM urn for the identifiers...
Compare Namespace and 'Root URN' at: http://identifiers.org/isbn/
I started looking at the IDMapper implementing of DataCollection, but
will send a separate email about that...
Christian brenninkmeijer
I like the idea of supporting MIRIAM from a DataCollection.
It is in fact better placed there than DataSource as several DataSources
can have the same MIRIAM id.
I would however high encourage that the mthods names for MIRIAM are
consitent between DataSource and DataCollection.
Perosnally I don't like the method names
public Builder urnBase (String base)
and
public String getURN(String id)
But unless the project is wiling to refactor these names I suggest we
stick with them in all Objects that support MIRIAM.
On 06/03/2012 13:26, Egon Willighagen wrote:
> Hi Christian,
>
> thanx for your feedback!
>
> On Tue, Mar 6, 2012 at 10:30 AM, Christian brenninkmeijer
> <"Christian"@mygrid.org.uk> wrote:
>> However I struggle to understand what the "namespace" variable is intended
>> for.
> The namespace returns in the MIRIAM urn for the identifiers...
>
> Compare Namespace and 'Root URN' at: http://identifiers.org/isbn/
>
> I started looking at the IDMapper implementing of DataCollection, but
> will send a separate email about that...
>
> Egon
>
--
Egon Willighagen
<"Christian"@mygrid.org.uk> wrote:
> I would however high encourage that the mthods names for MIRIAM are
> consitent between DataSource and DataCollection.
> Perosnally I don't like the method names
> public Builder urnBase (String base)
> and
> public String getURN(String id)
I second that... Martijn, can we discuss getting method names in line
with MIRIAM / identifiers.org... ?