[Obi-devel] Changing our URIs to be PURL based
Alan Ruttenberg
finalize policy on what the purls will look like. Here are the
choices as I see them (All of these choices work find in protege,
btw, and all are consistent with OBO Foundry principles, afaik)
1) Current OBO practice.
Example URI: http://purl.org/obo/owl/OBI#OBI_0010000
Pro: Current OBO practice.
Cons: "owl" in name doesn't make sense. # (hash) doesn't scale well
if you want to have each term resolve to just a bit of owl about the
term (which is desirable) because web servers don't get the part of
the URI after the "#". So an HTTP GET of any OBI URI returns the
whole ontology, which over time we hope to have be rather large, and
hence this is undesirable behavior.
2) Somewhat conservative change:
Example URI: http://purl.org/obo/OBI/OBI_0010000
Pro: "/" instead of "#" gets rid of problem named above. No "owl" in
the name.
Cons: More verbose than necessary - we see "OBI" twice in the URI for
classes.
3) Closest to what I think it should be
Example URI: http://purl.org/obo/OBI_0010000
Pro: As short as is sensible.
Cons: Issue with terms that don't have OBI ids, such as relations,
instances, and classes that we might want to keep named (Bill's new
CurationStatus?)
How to address?
either
a) relations,etc look like this instead: http://purl.org/obo/OBI/
is_proxy_for - note that there are two namespaces that we occupy:
http://purl.org/obo/
http://purl.org/obo/OBI/
(but perhaps we shouldn't care - namespaces aren't anything but
abbreviations in RDF)
or
b) We strictly use OBI ids for *everything*, including relations.
----
Chris Mungall has expressed the preference that we perhaps keep the
current OBO practice and then change all of OBO at once (he's
sympathetic to the issues). My counter is that we are changing now
and it would be nice to not change again - perhaps we can be the
leading wave for OBO.
My strong preference is for 3) - either a) or b) is satisfactory in
my view. I find 2) acceptable, if not as aesthetically pleasing, and
I am opposed to 1)
We're supposed to release tomorrow and it would be nice to release
with a scheme that will be stable. The script I've written has been
tested and can generate any of these possibilities with a couple of
edits. It would be nice if we could come to a quick consensus about
this. Please let me know your thoughts.
-Alan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Obi-devel mailing list
Obi-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/obi-devel
Melanie Courtot
I agree that if we are doing the change now we might as well go for the
stable solution and not change again later on (especially if we know that
the change will be made to the rest of OBO)
I like the 3rd option. I would rather choose 3 b., assigning IDs to
everything, but I don't have a strong opinion about that.
Thanks,
Melanie
Alan Ruttenberg
mentions 6 digit ids. I had looked at GO and saw 7 digits and assumed
that's what my script should produce. Anyone in favor of keeping 6
digit versus 7 please shout.
Oops - just noticed that the current files also have 7 and 8 digit
ids to. Erg - better adjust my script to reallocate the 8 digit ones
lower.
-Alan
Trish Whetzel
As far as the number of digits in the ID, although there is not 100% consistency amongst OBO ontologies to use 7 digits, that is the case with GO, SO, PATO, UO so FWIW might was well use 7 digits.
Trish
Matthew Pocock
I am not sure what you are expecting there to be at the end of these URLs -
what are they intended to resolve to?
Matthew
Melanie Courtot
We wrote down a document about that:
http://docs.google.com/Doc?docid=dzprnmw_8fnr5nmd4&hl=en
This is still work in progress (we already need to update with few
comments) so let us know if you find anything unclear.
Thanks,
Melanie
Matthew Pocock
Look, I get that it is nice to have some sort of URL out there associated with
each concept in some way. What I still don't understand is what content is
returned when I contact that URL. Some human-readable text? Some lump of
axioms? Some reasoning service? The <url#id> form is the standard URI naming
scheim for OWL entities. Although not required, it is the default thing that
tools do. These are meant to be names/identifiers, and not inherently be
resolvable. However, this doesn't stop us hosting some document /about/ that
owl entity at a URL/PURL. You can't host the entity itself there
meaningfully, as there can be arbitrarily many axioms in arbitrarily many OWL
files that tell you things about that entity.
Does that make my query any clearer?
Matthew
> >>- This SF.net email is sponsored by: Microsoft
Alan Ruttenberg
debugging the xslt step. Short story: You get RDF/XML, with an xslt
directive that lets the browser display it in a pretty way.
-Alan
> On Mar 10, 2008, at 10:29 PM, Alan Ruttenberg wrote:
>
>> [this message as more of a brain dump than a proper explanation]
>>
>> They resolve to a trivial piece of RDF at the moment, but most of
>> the pieces are in place.
>>
>> 1) Had to create purl batch files of 100 ids each
>>
>> http://obi.svn.sourceforge.net/svnroot/obi/branchDevelopment/tags/
>> releases/2008-03-10/merged/new-purls*.xml
>>
>> Script sourcecodes/new-purls.lisp (I split it into batches - need
>> to make the script do that next time)
>>
>> Manual batch script loads (9 of them) at http://purl.org/maint/
>> batch_add.html
>>
>> 2) They redirect to e.g. http://sw.neurocommons.org/obiterm/
>> OBI_0302722
>>
>> Apache setup:
>>
>> Add line:
>>
>> Redirect 303 /obiterm/ http://sw.neurocommons.org/cgi-bin/
>> obiterm?ref=
>>
>> 3) Script in /var/www/cgi-bin/obiterm
>>
>> #!/usr/bin/perl -w
>> use CGI; # load CGI routines
>> my $query = new CGI; # create new CGI object
>> print $query->header(-type=>'application/rdf+xml');
>> while (<DATA>)
>> { print }
>> my $ref = $query->param('ref');
>> print "<rdf:Description rdf:about=\"http://purl.obofoundry.org/obo/
>> $ref\"/>\n";
>> print "</rdf:RDF>\n";
>>
>> __DATA__
>> <?xml version="1.0"?>
>> <?xml-stylesheet type="text/xsl" href="obiterm.xsl"?>
>>
>>
>> __DATA__
>> <?xml version="1.0"?>
>> <?xml-stylesheet type="text/xsl" href="obiterm.xsl"?>
>> <rdf:RDF xmlns="http://purl.obofoundry.org/obo/"
>> xmlns:owl="http://www.w3.org/2002/07/owl#"
>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>> >
>> <owl:Ontology rdf:about="">
>> <owl:imports>
>> <owl:Ontology rdf:about="http://purl.obofoundry.org/obo/
>> obi.owl"/>
>> </owl:imports>
>> </owl:Ontology>
>>
>> 4) Not working yet - there is a pointer to obiterm.xsl - this
>> needs to be made to work. I think we need mod-xslt.
>>
>> The end result is that you ask for http://purl.org/obo/OBI_0000225
>> you get the following traffic:
>>
>> GET /obo/OBI_0000225 HTTP/1.1
>> Accept-Language: en
>> Accept-Encoding: gzip, deflate
>> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)
>> AppleWebKit/523.12.2 (KHTML, like Gecko) Version/3.0.4 Safari/
>> 523.12.2
>> Accept: text/xml,application/xml,application/xhtml+xml,text/
>> html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>> Connection: keep-alive
>> Host: purl.oclc.org
>>
>> HTTP/1.1 302 Found
>> Date: Tue, 11 Mar 2008 05:17:27 GMT
>> Server: Apache/1.3.29
>> Location: http://sw.neurocommons.org/obiterm/OBI_0000225
>> Connection: close
>> Transfer-Encoding: chunked
>> Content-Type: text/html; charset=iso-8859-1
>>
>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>> <HTML><HEAD>
>> <TITLE>302 Found</TITLE>
>> </HEAD><BODY>
>> <H1>Found</H1>
>> The document has moved <A HREF="http://sw.neurocommons.org/obiterm/
>> OBI_0000225">here</A>.<P>
>> </BODY></HTML>
>>
>>
>> GET /obiterm/OBI_0000225 HTTP/1.1
>> Accept: */*
>> Accept-Language: en
>> Accept-Encoding: gzip, deflate
>> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)
>> AppleWebKit/523.12.2 (KHTML, like Gecko) Version/3.0.4 Safari/
>> 523.12.2
>> Connection: keep-alive
>> Host: sw.neurocommons.org
>>
>> HTTP/1.1 303 See Other
>> Date: Tue, 11 Mar 2008 05:17:39 GMT
>> Server: Apache/2.0.52 (CentOS)
>> Location: http://sw.neurocommons.org/cgi-bin/obiterm?ref=OBI_0000225
>> Content-Length: 350
>> Connection: close
>> Content-Type: text/html; charset=iso-8859-1
>>
>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>> <html><head>
>> <title>303 See Other</title>
>> </head><body>
>> <h1>See Other</h1>
>> <p>The answer to your request is located <a href="http://
>> sw.neurocommons.org/cgi-bin/obiterm?ref=OBI_0000225">here</a>.</p>
>> <hr>
>> <address>Apache/2.0.52 (CentOS) Server at sw.neurocommons.org Port
>> 80</address>
>> </body></html>
>>
>> GET /cgi-bin/obiterm?ref=OBI_0000225 HTTP/1.1
>> Accept: */*
>> Accept-Language: en
>> Accept-Encoding: gzip, deflate
>> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)
>> AppleWebKit/523.12.2 (KHTML, like Gecko) Version/3.0.4 Safari/
>> 523.12.2
>> Connection: keep-alive
>> Host: sw.neurocommons.org
>>
>> HTTP/1.1 200 OK
>> Date: Tue, 11 Mar 2008 05:17:39 GMT
>> Server: Apache/2.0.52 (CentOS)
>> Connection: close
>> Transfer-Encoding: chunked
>> Content-Type: application/rdf+xml
>>
>> <?xml version="1.0"?>
>> <?xml-stylesheet type="text/xsl" href="obiterm.xsl"?>
>> <rdf:RDF xmlns="http://purl.obofoundry.org/obo/"
>> xmlns:owl="http://www.w3.org/2002/07/owl#"
>> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>> >
>> <owl:Ontology rdf:about="">
>> <owl:imports>
>> <owl:Ontology rdf:about="http://purl.obofoundry.org/obo/
>> obi.owl"/>
>> </owl:imports>
>> </owl:Ontology>
>> <rdf:Description rdf:about="http://purl.obofoundry.org/obo/
>> OBI_0000225"/>
>> </rdf:RDF>