From Jesus.Salgado at sciops.esa.int Mon Oct 10 06:14:44 2011 From: Jesus.Salgado at sciops.esa.int (Jesus Salgado) Date: Mon, 10 Oct 2011 15:14:44 +0200 Subject: DM sessions at Pune Message-ID: <31979_1318252478_4E92EFBE_31979_201878_2_1318252484.1807.551.camel@satl11.net4.lan> Dear DM-ers, I have published the agenda for next interop DM sessions at: http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/InterOpOct2011DM If you are an speaker, please feel free to edit the wiki for any modification on the title or time allocation. If you would like to present something and you are not into the schedule yet, please let me know to find possible solutions. Best Regards, -- Jesus J. SALGADO Jesus.Salgado at sciops.esa.int ESAC Science Archives Team European Space Astronomy Centre (ESAC) European Space Agency (ESA) European Space Agency/European Space Astronomy Centre P.O. Box 78 28691 Villanueva de la Canada Tel: +34 91 813 12 71 Madrid - SPAIN Fax: +34 91 813 13 08 ------------------------------------------------------------------- ================================================================================================ This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. ================================================================================================= From chil at sai.msu.ru Mon Oct 17 10:54:43 2011 From: chil at sai.msu.ru (Igor Chilingarian) Date: Mon, 17 Oct 2011 21:54:43 +0400 (MSD) Subject: no Characterisation DM on arXiv Message-ID: Hi, Reading the IVOA newsletter I've noticed that Characterisaion Data Model was not put on the arXiv as all other IVOA Recommendations, although it has the "recommendation" status since a long time. Is there any particular reason for this? With best regards, Igor From ivoadoc at ivoa.net Mon Oct 17 10:57:44 2011 From: ivoadoc at ivoa.net (IVOA Document Coordinator) Date: Mon, 17 Oct 2011 10:57:44 -0700 Subject: no Characterisation DM on arXiv In-Reply-To: References: Message-ID: <4E9C6C98.2030901@ivoa.net> Hi, Yes, there is! Unfortunately arXiv is very picky about the format of the PDF files it accepts and for some reason it wouldn't accept that one no matter what I tried. I'm working with Mireille on getting a new version to publish there. Stay tuned! Hopefully soon... Sarah On 10/17/11 10:54 AM, Igor Chilingarian wrote: > Hi, > > Reading the IVOA newsletter I've noticed that Characterisaion Data Model > was not put on the arXiv as all other IVOA Recommendations, although it > has the "recommendation" status since a long time. Is there any > particular reason for this? > > With best regards, > Igor From olaurino at head.cfa.harvard.edu Thu Oct 20 00:34:28 2011 From: olaurino at head.cfa.harvard.edu (Omar Laurino) Date: Thu, 20 Oct 2011 03:34:28 -0400 Subject: Utypes Mailing List Message-ID: Dear Data Modelers, As you might know, we are going to create a discussion list for coordinating the effort of finalizing the Utypes specification. I am taking the lead of this effort so, if you are interested in the discussion, please reply to this email to sign up. I will add you to the list as soon as we create it. Please make sure you reply to me only (olaurino at head.cfa.harvard.edu) in order to avoid annoying spam ;) Thank you, Omar. -- Omar Laurino Smithsonian Astrophysical Observatory Harvard-Smithsonian Center for Astrophysics 100 Acorn Park Dr. R-376 MS-81 02140 Cambridge, MA (617) 495-7227 -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.bonnarel at astro.unistra.fr Thu Oct 20 01:31:07 2011 From: francois.bonnarel at astro.unistra.fr (=?ISO-8859-1?Q?Fran=E7ois_Bonnarel?=) Date: Thu, 20 Oct 2011 10:31:07 +0200 Subject: Utypes Mailing List In-Reply-To: References: Message-ID: <4E9FDC4B.8080302@astro.unistra.fr> Hi Omar, I would like to participate Cheers Fran?ois Le 20/10/2011 09:34, Omar Laurino a ?crit : > Dear Data Modelers, > > As you might know, we are going to create a discussion list for > coordinating the effort of finalizing the Utypes specification. > > I am taking the lead of this effort so, if you are interested in the > discussion, please reply to this email to sign up. I will add you to > the list as soon as we create it. > > Please make sure you reply to me only (olaurino at head.cfa.harvard.edu > ) in order to avoid annoying spam ;) > > Thank you, > > Omar. > > -- > Omar Laurino > Smithsonian Astrophysical Observatory > Harvard-Smithsonian Center for Astrophysics > 100 Acorn Park Dr. R-376 MS-81 > 02140 Cambridge, MA > (617) 495-7227 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jesus.Salgado at sciops.esa.int Thu Oct 20 02:11:05 2011 From: Jesus.Salgado at sciops.esa.int (Jesus Salgado) Date: Thu, 20 Oct 2011 11:11:05 +0200 Subject: SimDM 1.0 enters into the TCG review phase Message-ID: <8875_1319101863_4E9FE5A7_8875_37040_2_4E9FE5A9.7010607@sciops.esa.int> Dear all, After latest updated version uploaded by Herv? today and a verification that this version covers the main issues found during the RFC, SimDM 1.0 enters officially into TCG review phase. RFC page can be found here: http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SimRFC All the documents can be found there: http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/IVOATheorySimDMspec The review will be opened from Oct 20th to Nov 20th. Best regards, Jesus Salgado DM WG Chair ================================================================================================ This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. ================================================================================================= From Jesus.Salgado at sciops.esa.int Tue Oct 25 03:44:59 2011 From: Jesus.Salgado at sciops.esa.int (Jesus Salgado) Date: Tue, 25 Oct 2011 12:44:59 +0200 Subject: Photometry data model v1.0 working draft Message-ID: <2705_1319539483_4EA6931B_2705_22300_1_4EA6932B.8060409@sciops.esa.int> Dear Data Modelers, A new version of the Photometry Data Model (v1.0) can be found at the following location: http://www.ivoa.net/internal/IVOA/PhotometryDataModel/WD-PhotDM-1.0-20111013.pdf (the document has been also sent to the document coordinator to update the relevant page) There is also a discussion list at: http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/PhotDiscussion This draft initiates a four weeks period of comments within the working group. Please read the document carefully and provide comments now. Comments will be really welcome and appreciated. Best Regards, Jesus ================================================================================================ This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. ================================================================================================= From patrick.dowler at nrc-cnrc.gc.ca Tue Oct 25 12:44:44 2011 From: patrick.dowler at nrc-cnrc.gc.ca (Patrick Dowler) Date: Tue, 25 Oct 2011 12:44:44 -0700 Subject: how to make a publisherDID Message-ID: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> I need to decide on a procedure for making publisherDID values for use in TAP services, for example in the ivoa.ObsCore table, but also our internal CAOM tables which also expose the same identifiers. This is following from the interesting DAL-DM-DCP discussions on use of URIs. Presumably, I could start with a DataCollection identifier registered in the IVOA registry system, eg: ivo://cadc.nrc.ca/archive/cfht (note: more generally, a creatorDID would be linked to a DataCollection and a publisherDID might be linked to a provider/service in case they are not the same or definitive provider - let's ignore that for now) In the past we would use the fragment, eg ivo://cadc.nrc.ca/archive/cfht#12345/raw but that implies that one can somehow "get" the entire collection and then look for "12345/raw" inside it (client side). Instead, I could append some dataset-specific to get an observation identifier, eg. ivo://cadc.nrc.ca/archive/cfht/12345 and then append something product-specific to get an identifier for the product, eg. ivo://cadc.nrc.ca/archive/cfht/12345/raw However, if someone has one of these (the last one), what can they do with it? With this approach, there is no prescribed way to extract the identifier for the registered DataCollection. Should there be? In VOSpace, the spec invents a new URI scheme (vos) that prescribes exactly how to extract/create the service URI from the vos URI, but it comes down to being able to separate the URI into two halves: a base that can be looked up in a registry and a separate bit (path in vos) that can be used when talking to the service. In principle this does not require a new scheme, but it does require at least a way to separate. PS-I have the exact same issue with several services where I want to identify the service with an ivo URI and I want to make and use URIs for items found within/via that service. -- Patrick Dowler Tel/T?l: (250) 363-0044 Canadian Astronomy Data Centre National Research Council Canada 5071 West Saanich Road Victoria, BC V9E 2M7 Centre canadien de donnees astronomiques Conseil national de recherches Canada 5071, chemin West Saanich Victoria (C.-B.) V9E 2M7 From dtody at nrao.edu Tue Oct 25 13:14:26 2011 From: dtody at nrao.edu (Douglas Tody) Date: Tue, 25 Oct 2011 14:14:26 -0600 (MDT) Subject: how to make a publisherDID In-Reply-To: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> References: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> Message-ID: Maybe I am missing something but this seems pretty cut and dried... A publisherDID (dataset identifier) is just another DID, the only thing different from other DIDs being context or usage. So it consists of a registered authority ID concatenated with a user-defined resource key, as defined in http://www.ivoa.net/Documents/REC/Identifiers/Identifiers-20070302.html So the publisher (e.g. archive) registers an authority ID, which globally defines a namespace they control, within which they can assign resource/ dataset keys which are unique within the namespace. Since the authority ID is globally unique the publisherDIDs will be too. I am not sure it is required by the standard but usually the collection name is appended to the authority ID, i.e. multiple collections can share the same publisherDID namespace. About all one could safely extract from the pubDID is the authority ID since the resource key syntax is not fixed. But this could be sufficient to find an associated ObsTAP service, and given the pubDID one can query this to get the observation ID, collection name, and other metadata. - Doug On Tue, 25 Oct 2011, Patrick Dowler wrote: > > I need to decide on a procedure for making publisherDID values for use in TAP > services, for example in the ivoa.ObsCore table, but also our internal CAOM > tables which also expose the same identifiers. This is following from the > interesting DAL-DM-DCP discussions on use of URIs. > > Presumably, I could start with a DataCollection identifier registered in the > IVOA registry system, eg: > > ivo://cadc.nrc.ca/archive/cfht > > (note: more generally, a creatorDID would be linked to a DataCollection and a > publisherDID might be linked to a provider/service in case they are not the > same or definitive provider - let's ignore that for now) > > In the past we would use the fragment, eg > ivo://cadc.nrc.ca/archive/cfht#12345/raw but that implies that one can somehow > "get" the entire collection and then look for "12345/raw" inside it (client > side). > > Instead, I could append some dataset-specific to get an observation identifier, > eg. > > ivo://cadc.nrc.ca/archive/cfht/12345 > > and then append something product-specific to get an identifier for the product, > eg. > > ivo://cadc.nrc.ca/archive/cfht/12345/raw > > However, if someone has one of these (the last one), what can they do with it? > With this approach, there is no prescribed way to extract the identifier for > the registered DataCollection. Should there be? > > In VOSpace, the spec invents a new URI scheme (vos) that prescribes exactly > how to extract/create the service URI from the vos URI, but it comes down to > being able to separate the URI into two halves: a base that can be looked up > in a registry and a separate bit (path in vos) that can be used when talking > to the service. In principle this does not require a new scheme, but it does > require at least a way to separate. > > PS-I have the exact same issue with several services where I want to identify > the service with an ivo URI and I want to make and use URIs for items found > within/via that service. > > -- > > Patrick Dowler > Tel/T?l: (250) 363-0044 > Canadian Astronomy Data Centre > National Research Council Canada > 5071 West Saanich Road > Victoria, BC V9E 2M7 > > Centre canadien de donnees astronomiques > Conseil national de recherches Canada > 5071, chemin West Saanich > Victoria (C.-B.) V9E 2M7 > From m.b.taylor at bristol.ac.uk Wed Oct 26 01:10:13 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Wed, 26 Oct 2011 09:10:13 +0100 (BST) Subject: how to make a publisherDID In-Reply-To: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> References: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> Message-ID: Pat, URI permits a query part, so one possible way would be something like: ivo://cadc.nrc.ca/archive/cfht?observation=12345&product=raw As far as I can see this would in principle solve the parsability issues you're looking at, and it's more flexible than putting everything in one hierarchical path. It's probably a good enough solution for human users. However, given that it's not currently standardised, the answer to how a machine holding one of these actually works out what it means [still] relies on it's understanding your particular conventions for encoding the information in a URI. Whether a human and/or machine actually *needs* to understand what it means is another question, I'm not involved enough with this stuff to have an opinion. Mark On Tue, 25 Oct 2011, Patrick Dowler wrote: > I need to decide on a procedure for making publisherDID values for use in TAP > services, for example in the ivoa.ObsCore table, but also our internal CAOM > tables which also expose the same identifiers. This is following from the > interesting DAL-DM-DCP discussions on use of URIs. > > Presumably, I could start with a DataCollection identifier registered in the > IVOA registry system, eg: > > ivo://cadc.nrc.ca/archive/cfht > > (note: more generally, a creatorDID would be linked to a DataCollection and a > publisherDID might be linked to a provider/service in case they are not the > same or definitive provider - let's ignore that for now) > > In the past we would use the fragment, eg > ivo://cadc.nrc.ca/archive/cfht#12345/raw but that implies that one can somehow > "get" the entire collection and then look for "12345/raw" inside it (client > side). > > Instead, I could append some dataset-specific to get an observation identifier, > eg. > > ivo://cadc.nrc.ca/archive/cfht/12345 > > and then append something product-specific to get an identifier for the product, > eg. > > ivo://cadc.nrc.ca/archive/cfht/12345/raw > > However, if someone has one of these (the last one), what can they do with it? > With this approach, there is no prescribed way to extract the identifier for > the registered DataCollection. Should there be? > > In VOSpace, the spec invents a new URI scheme (vos) that prescribes exactly > how to extract/create the service URI from the vos URI, but it comes down to > being able to separate the URI into two halves: a base that can be looked up > in a registry and a separate bit (path in vos) that can be used when talking > to the service. In principle this does not require a new scheme, but it does > require at least a way to separate. > > PS-I have the exact same issue with several services where I want to identify > the service with an ivo URI and I want to make and use URIs for items found > within/via that service. > > -- > > Patrick Dowler > Tel/T?l: (250) 363-0044 > Canadian Astronomy Data Centre > National Research Council Canada > 5071 West Saanich Road > Victoria, BC V9E 2M7 > > Centre canadien de donnees astronomiques > Conseil national de recherches Canada > 5071, chemin West Saanich > Victoria (C.-B.) V9E 2M7 > -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From dtody at nrao.edu Wed Oct 26 04:55:17 2011 From: dtody at nrao.edu (Douglas Tody) Date: Wed, 26 Oct 2011 05:55:17 -0600 (MDT) Subject: how to make a publisherDID In-Reply-To: References: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> Message-ID: But this is a query string and not a fixed identifier of the sort we want to use to index archives; the pubDID will often be used as an actual key to build DBMS indexes (the proposed syntax might work technically as a key but is not in the spirit of what is intended for a DID). Also this contains reserved characters which are not currently legal in an IVOA dataset identifier ('?', '&', probably '='). Everything which is legal in URI is not necessarily legal in an IVOA dataset identifier. I don't see any reason to change the simple nature of a DID which is an authority ID concatenated with a (unspecified format) resource key. We just need to use this as a simple key as intended to go look up additional information stored elsewhere. The pubDID can be used to find the ObsCore record for a data product which contains detailed information in a standardized form. The authority ID can be parsed off and used to access a registry record which can be extended if we need to store additional information at that level. - Doug On Wed, 26 Oct 2011, Mark Taylor wrote: > Pat, > > URI permits a query part, so one possible way would be something like: > > ivo://cadc.nrc.ca/archive/cfht?observation=12345&product=raw > > As far as I can see this would in principle solve the parsability > issues you're looking at, and it's more flexible than putting > everything in one hierarchical path. It's probably a good enough > solution for human users. However, given that it's not > currently standardised, the answer to how a machine holding one > of these actually works out what it means [still] relies on > it's understanding your particular conventions for encoding > the information in a URI. Whether a human and/or machine actually > *needs* to understand what it means is another question, I'm not > involved enough with this stuff to have an opinion. > > Mark > > On Tue, 25 Oct 2011, Patrick Dowler wrote: > >> I need to decide on a procedure for making publisherDID values for use in TAP >> services, for example in the ivoa.ObsCore table, but also our internal CAOM >> tables which also expose the same identifiers. This is following from the >> interesting DAL-DM-DCP discussions on use of URIs. >> >> Presumably, I could start with a DataCollection identifier registered in the >> IVOA registry system, eg: >> >> ivo://cadc.nrc.ca/archive/cfht >> >> (note: more generally, a creatorDID would be linked to a DataCollection and a >> publisherDID might be linked to a provider/service in case they are not the >> same or definitive provider - let's ignore that for now) >> >> In the past we would use the fragment, eg >> ivo://cadc.nrc.ca/archive/cfht#12345/raw but that implies that one can somehow >> "get" the entire collection and then look for "12345/raw" inside it (client >> side). >> >> Instead, I could append some dataset-specific to get an observation identifier, >> eg. >> >> ivo://cadc.nrc.ca/archive/cfht/12345 >> >> and then append something product-specific to get an identifier for the product, >> eg. >> >> ivo://cadc.nrc.ca/archive/cfht/12345/raw >> >> However, if someone has one of these (the last one), what can they do with it? >> With this approach, there is no prescribed way to extract the identifier for >> the registered DataCollection. Should there be? >> >> In VOSpace, the spec invents a new URI scheme (vos) that prescribes exactly >> how to extract/create the service URI from the vos URI, but it comes down to >> being able to separate the URI into two halves: a base that can be looked up >> in a registry and a separate bit (path in vos) that can be used when talking >> to the service. In principle this does not require a new scheme, but it does >> require at least a way to separate. >> >> PS-I have the exact same issue with several services where I want to identify >> the service with an ivo URI and I want to make and use URIs for items found >> within/via that service. >> >> -- >> >> Patrick Dowler >> Tel/T?l: (250) 363-0044 >> Canadian Astronomy Data Centre >> National Research Council Canada >> 5071 West Saanich Road >> Victoria, BC V9E 2M7 >> >> Centre canadien de donnees astronomiques >> Conseil national de recherches Canada >> 5071, chemin West Saanich >> Victoria (C.-B.) V9E 2M7 >> > > -- > Mark Taylor Astronomical Programmer Physics, Bristol University, UK > m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From m.b.taylor at bristol.ac.uk Wed Oct 26 04:59:00 2011 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Wed, 26 Oct 2011 12:59:00 +0100 (BST) Subject: how to make a publisherDID In-Reply-To: References: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> Message-ID: If (at least) '?' is not legal in this context, then my suggestion is clearly a non-starter - please consider it retracted. Mark On Wed, 26 Oct 2011, Douglas Tody wrote: > But this is a query string and not a fixed identifier of the sort we > want to use to index archives; the pubDID will often be used as an > actual key to build DBMS indexes (the proposed syntax might work > technically as a key but is not in the spirit of what is intended for a > DID). Also this contains reserved characters which are not currently > legal in an IVOA dataset identifier ('?', '&', probably '='). > Everything which is legal in URI is not necessarily legal in an IVOA > dataset identifier. > > I don't see any reason to change the simple nature of a DID which is an > authority ID concatenated with a (unspecified format) resource key. We > just need to use this as a simple key as intended to go look up > additional information stored elsewhere. The pubDID can be used to find > the ObsCore record for a data product which contains detailed > information in a standardized form. The authority ID can be parsed off > and used to access a registry record which can be extended if we need to > store additional information at that level. > > - Doug > > On Wed, 26 Oct 2011, Mark Taylor wrote: > > > Pat, > > > > URI permits a query part, so one possible way would be something like: > > > > ivo://cadc.nrc.ca/archive/cfht?observation=12345&product=raw > > > > As far as I can see this would in principle solve the parsability > > issues you're looking at, and it's more flexible than putting > > everything in one hierarchical path. It's probably a good enough > > solution for human users. However, given that it's not > > currently standardised, the answer to how a machine holding one > > of these actually works out what it means [still] relies on > > it's understanding your particular conventions for encoding > > the information in a URI. Whether a human and/or machine actually > > *needs* to understand what it means is another question, I'm not > > involved enough with this stuff to have an opinion. > > > > Mark > > > > On Tue, 25 Oct 2011, Patrick Dowler wrote: > > > > > I need to decide on a procedure for making publisherDID values for use in > > > TAP > > > services, for example in the ivoa.ObsCore table, but also our internal > > > CAOM > > > tables which also expose the same identifiers. This is following from the > > > interesting DAL-DM-DCP discussions on use of URIs. > > > > > > Presumably, I could start with a DataCollection identifier registered in > > > the > > > IVOA registry system, eg: > > > > > > ivo://cadc.nrc.ca/archive/cfht > > > > > > (note: more generally, a creatorDID would be linked to a DataCollection > > > and a > > > publisherDID might be linked to a provider/service in case they are not > > > the > > > same or definitive provider - let's ignore that for now) > > > > > > In the past we would use the fragment, eg > > > ivo://cadc.nrc.ca/archive/cfht#12345/raw but that implies that one can > > > somehow > > > "get" the entire collection and then look for "12345/raw" inside it > > > (client > > > side). > > > > > > Instead, I could append some dataset-specific to get an observation > > > identifier, > > > eg. > > > > > > ivo://cadc.nrc.ca/archive/cfht/12345 > > > > > > and then append something product-specific to get an identifier for the > > > product, > > > eg. > > > > > > ivo://cadc.nrc.ca/archive/cfht/12345/raw > > > > > > However, if someone has one of these (the last one), what can they do with > > > it? > > > With this approach, there is no prescribed way to extract the identifier > > > for > > > the registered DataCollection. Should there be? > > > > > > In VOSpace, the spec invents a new URI scheme (vos) that prescribes > > > exactly > > > how to extract/create the service URI from the vos URI, but it comes down > > > to > > > being able to separate the URI into two halves: a base that can be looked > > > up > > > in a registry and a separate bit (path in vos) that can be used when > > > talking > > > to the service. In principle this does not require a new scheme, but it > > > does > > > require at least a way to separate. > > > > > > PS-I have the exact same issue with several services where I want to > > > identify > > > the service with an ivo URI and I want to make and use URIs for items > > > found > > > within/via that service. > > > > > > -- > > > > > > Patrick Dowler > > > Tel/T?l: (250) 363-0044 > > > Canadian Astronomy Data Centre > > > National Research Council Canada > > > 5071 West Saanich Road > > > Victoria, BC V9E 2M7 > > > > > > Centre canadien de donnees astronomiques > > > Conseil national de recherches Canada > > > 5071, chemin West Saanich > > > Victoria (C.-B.) V9E 2M7 > > > > > > > -- > > Mark Taylor Astronomical Programmer Physics, Bristol University, UK > > m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/ From dtody at nrao.edu Wed Oct 26 07:33:08 2011 From: dtody at nrao.edu (Douglas Tody) Date: Wed, 26 Oct 2011 08:33:08 -0600 (MDT) Subject: how to make a publisherDID In-Reply-To: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> References: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> Message-ID: On Tue, 25 Oct 2011, Patrick Dowler wrote: > In the past we would use the fragment, eg > ivo://cadc.nrc.ca/archive/cfht#12345/raw but that implies that one can somehow > "get" the entire collection and then look for "12345/raw" inside it (client > side). > > Instead, I could append some dataset-specific to get an observation identifier, > eg. > > ivo://cadc.nrc.ca/archive/cfht/12345 > > and then append something product-specific to get an identifier for the product, > eg. > > ivo://cadc.nrc.ca/archive/cfht/12345/raw So far as conventions go my preference is still for something like ivo://cadc.nrc.ca/archive/cfht#12345/raw where the convention is that ivo:/// (everything before the #) is also the collection identifier and the remainder is the specific data product ID within the collection. Perhaps this should eventually be more than just a convention. We could try to carry this down to the observation level, but that will get too collection specific (e.g., "observation" is not all that well defined for example hence should be up to the DP). Also there are cases where we want to allow the DP to keep their old familiar data product identifiers, and they often can so long as well do not try to overly constrain what is to the right of the #. Of course this need not prevent the DP from following a consistent scheme there as well such as you suggest. - Doug From patrick.dowler at nrc-cnrc.gc.ca Wed Oct 26 10:49:11 2011 From: patrick.dowler at nrc-cnrc.gc.ca (Patrick Dowler) Date: Wed, 26 Oct 2011 10:49:11 -0700 Subject: how to make a publisherDID In-Reply-To: References: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> Message-ID: <201110261049.12149.patrick.dowler@nrc-cnrc.gc.ca> On 2011-10-26 07:33:08 Douglas Tody wrote: > So far as conventions go my preference is still for something like > > ivo://cadc.nrc.ca/archive/cfht#12345/raw > > where the convention is that ivo:/// > (everything before the #) is also the collection identifier and the > remainder is the specific data product ID within the collection. > Perhaps this should eventually be more than just a convention. Yeah, I did this because the stuff before the # is in fact a regsistered DataCollection, but according to the discussions this means that there is one identified resource and that in principle one could resolve it, get it, and find the fragment within. That is definiotely *not* what we want to say. I can live with /, but if we want to enable someone with a publisherDID to find and download that dataset it presupposes that the client could find services owned/operated by that authority and invoke the service(s) with the publisherDID. Alternatively, if it means (in future) they look for a specific type of service under that authority then it is more or less manageable, but having multiple services is still problematic. I personally don't care much about that because we are trying very hard to provide common services across all our collections, but other people may not like it. I realise that publisherDIDs seem quite disconnected from using services, but I can't ignore this idea that being able to resolve them in a prescribed way seems like a really good idea. -- Patrick Dowler Tel/T?l: (250) 363-0044 Canadian Astronomy Data Centre National Research Council Canada 5071 West Saanich Road Victoria, BC V9E 2M7 Centre canadien de donnees astronomiques Conseil national de recherches Canada 5071, chemin West Saanich Victoria (C.-B.) V9E 2M7 From laurent.michel at astro.unistra.fr Wed Oct 26 14:27:57 2011 From: laurent.michel at astro.unistra.fr (Laurent.michel) Date: Wed, 26 Oct 2011 23:27:57 +0200 Subject: how to make a publisherDID Message-ID: Pas oblig? de tout mettre. On peut racourcir le use case peut etre Patrick Dowler a ?crit?: >On 2011-10-26 07:33:08 Douglas Tody wrote: >> So far as conventions go my preference is still for something like >> >> ivo://cadc.nrc.ca/archive/cfht#12345/raw >> >> where the convention is that ivo:/// >> (everything before the #) is also the collection identifier and the >> remainder is the specific data product ID within the collection. >> Perhaps this should eventually be more than just a convention. > >Yeah, I did this because the stuff before the # is in fact a regsistered >DataCollection, but according to the discussions this means that there is one >identified resource and that in principle one could resolve it, get it, and find >the fragment within. That is definiotely *not* what we want to say. > >I can live with /, but if we want to enable >someone with a publisherDID to find and download that dataset it presupposes >that the client could find services owned/operated by that authority and invoke >the service(s) with the publisherDID. Alternatively, if it means (in future) >they look for a specific type of service under that authority then it is more >or less manageable, but having multiple services is still problematic. I >personally don't care much about that because we are trying very hard to >provide common services across all our collections, but other people may not >like it. > >I realise that publisherDIDs seem quite disconnected from using services, but >I can't ignore this idea that being able to resolve them in a prescribed way >seems like a really good idea. > >-- > >Patrick Dowler >Tel/T?l: (250) 363-0044 >Canadian Astronomy Data Centre >National Research Council Canada >5071 West Saanich Road >Victoria, BC V9E 2M7 > >Centre canadien de donnees astronomiques >Conseil national de recherches Canada >5071, chemin West Saanich >Victoria (C.-B.) V9E 2M7 > From dtody at nrao.edu Wed Oct 26 15:41:59 2011 From: dtody at nrao.edu (Douglas Tody) Date: Wed, 26 Oct 2011 16:41:59 -0600 (MDT) Subject: how to make a publisherDID In-Reply-To: <201110261049.12149.patrick.dowler@nrc-cnrc.gc.ca> References: <201110251244.44979.patrick.dowler@nrc-cnrc.gc.ca> <201110261049.12149.patrick.dowler@nrc-cnrc.gc.ca> Message-ID: On Wed, 26 Oct 2011, Patrick Dowler wrote: > On 2011-10-26 07:33:08 Douglas Tody wrote: >> So far as conventions go my preference is still for something like >> >> ivo://cadc.nrc.ca/archive/cfht#12345/raw >> >> where the convention is that ivo:/// >> (everything before the #) is also the collection identifier and the >> remainder is the specific data product ID within the collection. >> Perhaps this should eventually be more than just a convention. > > Yeah, I did this because the stuff before the # is in fact a regsistered > DataCollection, but according to the discussions this means that there is one > identified resource and that in principle one could resolve it, get it, and find > the fragment within. That is definiotely *not* what we want to say. I don't understand this part - it is not how I thought this works. The DID points to a single data product. The authority ID is still there and unchanged in all these examples. There is nothing formal about collection in a DID so no implication regarding what one can do with the collection. > I can live with /, but if we want to enable > someone with a publisherDID to find and download that dataset it presupposes > that the client could find services owned/operated by that authority and invoke > the service(s) with the publisherDID. Yes - some extra registry capability may be needed to enable this. Or possibly a global indexing service that integrates and indexes all the data products. Then one could just search by the pubDID and the data links (if provided) would point to the relevant services. > Alternatively, if it means (in future) > they look for a specific type of service under that authority then it is more > or less manageable, but having multiple services is still problematic. I > personally don't care much about that because we are trying very hard to > provide common services across all our collections, but other people may not > like it. > > I realise that publisherDIDs seem quite disconnected from using services, but > I can't ignore this idea that being able to resolve them in a prescribed way > seems like a really good idea. We don't currently event require services like SIA/SSA etc. to provide search by pubDID but ultimately we will need to, once this is more broadly implemented. - Doug > -- > > Patrick Dowler > Tel/T?l: (250) 363-0044 > Canadian Astronomy Data Centre > National Research Council Canada > 5071 West Saanich Road > Victoria, BC V9E 2M7 > > Centre canadien de donnees astronomiques > Conseil national de recherches Canada > 5071, chemin West Saanich > Victoria (C.-B.) V9E 2M7 > From laurent.michel at astro.unistra.fr Wed Oct 26 23:15:12 2011 From: laurent.michel at astro.unistra.fr (Laurent MICHEL) Date: Thu, 27 Oct 2011 08:15:12 +0200 Subject: how to make a publisherDID In-Reply-To: References: Message-ID: <4EA8F6F0.6030809@astro.unistra.fr> Sorry the mistake, this strange message was not destinated the DM list of course Laqurent Sorry f Le 26/10/2011 23:27, Laurent.michel a ?crit : > Pas oblig? de tout mettre. On peut racourcir le use case peut etre > > Patrick Dowler a ?crit : > >> On 2011-10-26 07:33:08 Douglas Tody wrote: >>> So far as conventions go my preference is still for something like >>> >>> ivo://cadc.nrc.ca/archive/cfht#12345/raw >>> >>> where the convention is that ivo:/// >>> (everything before the #) is also the collection identifier and the >>> remainder is the specific data product ID within the collection. >>> Perhaps this should eventually be more than just a convention. >> >> Yeah, I did this because the stuff before the # is in fact a regsistered >> DataCollection, but according to the discussions this means that there is one >> identified resource and that in principle one could resolve it, get it, and find >> the fragment within. That is definiotely *not* what we want to say. >> >> I can live with/, but if we want to enable >> someone with a publisherDID to find and download that dataset it presupposes >> that the client could find services owned/operated by that authority and invoke >> the service(s) with the publisherDID. Alternatively, if it means (in future) >> they look for a specific type of service under that authority then it is more >> or less manageable, but having multiple services is still problematic. I >> personally don't care much about that because we are trying very hard to >> provide common services across all our collections, but other people may not >> like it. >> >> I realise that publisherDIDs seem quite disconnected from using services, but >> I can't ignore this idea that being able to resolve them in a prescribed way >> seems like a really good idea. >> >> -- >> >> Patrick Dowler >> Tel/T?l: (250) 363-0044 >> Canadian Astronomy Data Centre >> National Research Council Canada >> 5071 West Saanich Road >> Victoria, BC V9E 2M7 >> >> Centre canadien de donnees astronomiques >> Conseil national de recherches Canada >> 5071, chemin West Saanich >> Victoria (C.-B.) V9E 2M7 >> >