Difference: RI2Discussion (1 vs. 18)

Revision 182014-03-14 - MarkusDemleitner

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

RegTAP material

Changed:
<
<
RegTAP is now available as Working Draft from the IVOA document repository; what's in the document repo reflects the current status as of May 2013. The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.
>
>
RegTAP is now in RFC.
Added:
>
>
Any further discussion on RegTAP goes there.
 
Added:
>
>
The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.

Also: There is now a validation suite; see http://svn.ari.uni-heidelberg.de/svn/gavo/regtap-val

 There is a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]

A script for generating the schema for MySQL servers (requires version 5.6-4 at least, due to indexing solutions) is available here. Based upon the 2013-03-05 draft it includes also example UDF functions in MySQL scripting language. (M.Molinaro - 2013-04-10)

All this is an attempt to fulfill RestfulRegistryInterfaceReq.

See also Notes from the RegTAP talk at the Heidelberg Interop.

Related Material

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.

Requests for discussion/TODO

This is a list of questions Markus would appreciate input on. Feel free to add discussion points yourself as you see fit.

Please do comment in particular if you disagree with Markus' preference.

Deleted:
<
<
  • Do we need rules on lowercasing values in res_detail?
    • Pro (Markus' unloved Favourite; actually, I think this is one of the few real-life TINA situations): res_details values include URIs that must be matched case-insensitively, as well as, e.g., test query fragments that must not be destroyed by futzing with case. Unless we want to force people to remember to use case-insensitive matching (I can't remember stuff like this), there's no other way.
    • Con: There's too many rules already. People can ivo_nocasematch if they look for IVORNs in res_detail
    • Alternative (Markus' Utopia): Some of us enters a time machine, goes back ten years, and stops people from declaring all kinds of things as "case-insensitive".
  • Schema name: rr, ivoa, or yet something else?
    • Proposal 1: Keep the schema name as it is (Markus' Favourite)
      • Pro: No changes necessary, it's short and easy to type
      • Con: Obscore uses the ivoa schema; it seems kinda wrong to usurp further essentially random names.
    • Proposal 2: Insinuate all ivo_% like schema names are for IVOA standardized schemas and grab ivo_rr for the relational registry
      • Pro: the schema name makes clear that this is IVOA standardized while still keeping related tables together. This will scale to future data models that might be more complex than obscore
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
      • Con: it's a fairly intrusive change that doesn't seem to buy a lot
    • Proposal 3: Pull all the tables into the ivoa schema
      • Pro: Consistent with obscore
      • Con: The ivoa schema will become terribly messy
 
  • Add strict non-null conditions (rather than and/or in addition to the milder conditions currently imposed by the shoulds on primary and foreign keys)?
    • Pro: In-DB validation might lead to less junk users have to cope with; also, non-null conditions might help implementors
    • Con (Markus' Favourite): don't require anything. What's valid is defined by VOResource anyway, but if people can ingest slightly invalid data without breaking, why punish them (by declaring them in violation of the spec)?
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con (Markus' Favourite): it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH. Also, there's the question of namespace management: Require namespace declarations in all records? Allow them? Forbid them?
Changed:
<
<
  • Do we want creator_seq at all?
>
>
  • Should we have a table mapping prefixes to namespace URI, i.e., a canonical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc?
Deleted:
<
<
    • Pro (Markus' Favourite): Authors and author lists are, for better or worse, magic. Displaying them, and displaying them in order, is an absolute requirement for almost any UI. Not having creator_seq would imply sequence numbers in res_role and uglyfied queries, where there's indeed just this obsession to fix.
    • Con: Not in VOResource, needs logic in the ingestor. Also, since you can't predict what's in the creator fields (comma-separated list, semicolon-separated list, individual authors, something stranger yet), some author lists the ingestor creates will look odd in any case.
    • Alternative (Markus' Utopia): Change VOResource to actually mandate a certain format for creator (and atomic values). I'd still keep creator_seq, but at least its appearance would be predictable. Ah well.
  • Should we have a table mapping prefixes to namespace URI, i.e., a canoical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc?
 
    • Pro: clients can do schema discovery this way, FWIW; such data is necessary at least during OAI processing anyway. Also, it's a nice analog to the xmlns declaration in XML documents
    • Con: These mappings are largely static and are amended fairly slowly. Also note that it is intended that there are going to be multiple URI for a prefix (e.g., vs: already has two), so such a table is less straightforward than you may think
Changed:
<
<
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)?
>
>
Deleted:
<
<
    • Pro: This would be particularly convenient for the res_role that, since we deviate quite a bit from VOResource, look fairly odd in the RegTAP spec.
    • Con (Markus' Favourite): Changing VOResource is a major undertaking (all registries would have to update their records), and it seems we can do without. Let's.
  • Should we keep talking about utypes? Here, there's no Markus' Favourite since I don't like any of the proposals. Also note that currently, utypes are also used in keys in res_detail. Where's Alexander the Great when you need him?
    • Pro: They are what the VO has advertised as "pointing into data models" for quite a while now. It's significant work to change the current text to make those utypes go away. There's the utype column in TAP_SCHEMA, and it'll look odd if it is empty for an IVOA-sanctioned data model (implementation). Also, the obvious alternative xpaths leads to humonguously long strings.
    • Con: The utypes tiger team has come up with a (fairly sensible) document laying out what utypes should be in the future, and they're quite different from what we propose here.
    • Con: Let's use xpaths. They're easier to understand for people with less than five years VO experience, there's no battles for their interpretation. However, the question is: Xpaths where?
      • Proposal 1: actual xpaths into instance documents
        • Pro: almost immediately usable in a wide range of implementations
        • Con: How do we represent namespaces? As prefixes? As URI? Also, these beasts will become terribly long either way
      • Proposal 2: xpaths into the schema documents, which in turn could be identified through their canonical prefixes.
        • Pro: would work quite analogous to utypes, and they may be shorter
        • Con: xpaths into XSD are plain horrible, and they won't work anyway as soon as there's two 1:1 relations in the same object of the same type (doesn't currently happen in VOResource, but anyway)
      • Proposal 3: Introduce some shorthand convention to have xpaths into instances but still allow a compact representation (but how?)
  • Should we have a validation suite?
    • Pro (Markus Favourite): No question at all; a fairly small set of representative resource records and a set of test queries alongside with their results will help a lot in validating implementations
    • Con: It's work, and quite a bit of it. But well: that just means that help is highly appreciated.
 
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"
META FILEATTACHMENT attachment="RegTAP_MySQL_schema.sql" attr="" comment="MySQL (5.6-4+) flavoured schema creation, based on 2013-03-05 draft" date="1365587018" name="RegTAP_MySQL_schema.sql" path="RegTAP_MySQL_schema.sql" size="25678" user="MarcoMolinaro" version="1"

Revision 172013-05-31 - MenelaosPerdikeas

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

RegTAP material

Changed:
<
<
RegTAP is now available as
>
>
RegTAP is now available as Working Draft from the IVOA document repository; what's in the document repo reflects the current status as of May 2013. The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.
Deleted:
<
<
Working Draft from the IVOA document repository; what's in the document repo reflects the current status as of May 2013. The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.
  There is a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]

A script for generating the schema for MySQL servers (requires version 5.6-4 at least, due to indexing solutions) is available here. Based upon the 2013-03-05 draft it includes also example UDF functions in MySQL scripting language. (M.Molinaro - 2013-04-10)

Changed:
<
<
All this is an attempt to fullfil RestfulRegistryInterfaceReq.
>
>
All this is an attempt to fulfill RestfulRegistryInterfaceReq.
  See also Notes from the RegTAP talk at the Heidelberg Interop.

Related Material

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.

Requests for discussion/TODO

This is a list of questions Markus would appreciate input on. Feel free to add discussion points yourself as you see fit.

Please do comment in particular if you disagree with Markus' preference.

  • Do we need rules on lowercasing values in res_detail?
    • Pro (Markus' unloved Favourite; actually, I think this is one of the few real-life TINA situations): res_details values include URIs that must be matched case-insensitively, as well as, e.g., test query fragments that must not be destroyed by futzing with case. Unless we want to force people to remember to use case-insensitive matching (I can't remember stuff like this), there's no other way.
    • Con: There's too many rules already. People can ivo_nocasematch if they look for IVORNs in res_detail
    • Alternative (Markus' Utopia): Some of us enters a time machine, goes back ten years, and stops people from declaring all kinds of things as "case-insensitive".
  • Schema name: rr, ivoa, or yet something else?
    • Proposal 1: Keep the schema name as it is (Markus' Favourite)
      • Pro: No changes necessary, it's short and easy to type
      • Con: Obscore uses the ivoa schema; it seems kinda wrong to usurp further essentially random names.
Changed:
<
<
    • Proposal 2: Insinuate all ivo_% like schema names are for IVOA standardized schemas and grab ivo_rr for the relational registry
>
>
    • Proposal 2: Insinuate all ivo_% like schema names are for IVOA standardized schemas and grab ivo_rr for the relational registry
 
      • Pro: the schema name makes clear that this is IVOA standardized while still keeping related tables together. This will scale to future data models that might be more complex than obscore
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
      • Con: it's a fairly intrusive change that doesn't seem to buy a lot
    • Proposal 3: Pull all the tables into the ivoa schema
      • Pro: Consistent with obscore
      • Con: The ivoa schema will become terribly messy
  • Add strict non-null conditions (rather than and/or in addition to the milder conditions currently imposed by the shoulds on primary and foreign keys)?
    • Pro: In-DB validation might lead to less junk users have to cope with; also, non-null conditions might help implementors
    • Con (Markus' Favourite): don't require anything. What's valid is defined by VOResource anyway, but if people can ingest slightly invalid data without breaking, why punish them (by declaring them in violation of the spec)?
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con (Markus' Favourite): it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH. Also, there's the question of namespace management: Require namespace declarations in all records? Allow them? Forbid them?
  • Do we want creator_seq at all?
    • Pro (Markus' Favourite): Authors and author lists are, for better or worse, magic. Displaying them, and displaying them in order, is an absolute requirement for almost any UI. Not having creator_seq would imply sequence numbers in res_role and uglyfied queries, where there's indeed just this obsession to fix.
    • Con: Not in VOResource, needs logic in the ingestor. Also, since you can't predict what's in the creator fields (comma-separated list, semicolon-separated list, individual authors, something stranger yet), some author lists the ingestor creates will look odd in any case.
    • Alternative (Markus' Utopia): Change VOResource to actually mandate a certain format for creator (and atomic values). I'd still keep creator_seq, but at least its appearance would be predictable. Ah well.
  • Should we have a table mapping prefixes to namespace URI, i.e., a canoical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc?
Changed:
<
<
    • Pro: clients can do schema discovery this way, FWIW; such data is necessary at least during OAI processing anyway. Also, it's a nice analog to the xmlns declaration in XML documents
>
>
    • Pro: clients can do schema discovery this way, FWIW; such data is necessary at least during OAI processing anyway. Also, it's a nice analog to the xmlns declaration in XML documents
 
    • Con: These mappings are largely static and are amended fairly slowly. Also note that it is intended that there are going to be multiple URI for a prefix (e.g., vs: already has two), so such a table is less straightforward than you may think
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)?
    • Pro: This would be particularly convenient for the res_role that, since we deviate quite a bit from VOResource, look fairly odd in the RegTAP spec.
    • Con (Markus' Favourite): Changing VOResource is a major undertaking (all registries would have to update their records), and it seems we can do without. Let's.
  • Should we keep talking about utypes? Here, there's no Markus' Favourite since I don't like any of the proposals. Also note that currently, utypes are also used in keys in res_detail. Where's Alexander the Great when you need him?
    • Pro: They are what the VO has advertised as "pointing into data models" for quite a while now. It's significant work to change the current text to make those utypes go away. There's the utype column in TAP_SCHEMA, and it'll look odd if it is empty for an IVOA-sanctioned data model (implementation). Also, the obvious alternative xpaths leads to humonguously long strings.
    • Con: The utypes tiger team has come up with a (fairly sensible) document laying out what utypes should be in the future, and they're quite different from what we propose here.
    • Con: Let's use xpaths. They're easier to understand for people with less than five years VO experience, there's no battles for their interpretation. However, the question is: Xpaths where?
      • Proposal 1: actual xpaths into instance documents
        • Pro: almost immediately usable in a wide range of implementations
        • Con: How do we represent namespaces? As prefixes? As URI? Also, these beasts will become terribly long either way
      • Proposal 2: xpaths into the schema documents, which in turn could be identified through their canonical prefixes.
        • Pro: would work quite analogous to utypes, and they may be shorter
        • Con: xpaths into XSD are plain horrible, and they won't work anyway as soon as there's two 1:1 relations in the same object of the same type (doesn't currently happen in VOResource, but anyway)
      • Proposal 3: Introduce some shorthand convention to have xpaths into instances but still allow a compact representation (but how?)
  • Should we have a validation suite?
    • Pro (Markus Favourite): No question at all; a fairly small set of representative resource records and a set of test queries alongside with their results will help a lot in validating implementations
    • Con: It's work, and quite a bit of it. But well: that just means that help is highly appreciated.
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"
META FILEATTACHMENT attachment="RegTAP_MySQL_schema.sql" attr="" comment="MySQL (5.6-4+) flavoured schema creation, based on 2013-03-05 draft" date="1365587018" name="RegTAP_MySQL_schema.sql" path="RegTAP_MySQL_schema.sql" size="25678" user="MarcoMolinaro" version="1"

Revision 162013-05-23 - MarkusDemleitner

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

Changed:
<
<
The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://docs.g-vo.org/ridraft (also as PDF). The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.
>
>

RegTAP material

 
Changed:
<
<
Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]
>
>
RegTAP is now available as
Added:
>
>
Working Draft from the IVOA document repository; what's in the document repo reflects the current status as of May 2013. The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.
 
Added:
>
>
There is a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]
 A script for generating the schema for MySQL servers (requires version 5.6-4 at least, due to indexing solutions) is available here. Based upon the 2013-03-05 draft it includes also example UDF functions in MySQL scripting language. (M.Molinaro - 2013-04-10)
Changed:
<
<
There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.
>
>
All this is an attempt to fullfil RestfulRegistryInterfaceReq.
 
Changed:
<
<
There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.
>
>
See also Notes from the RegTAP talk at the Heidelberg Interop.
 
Changed:
<
<
All this is an attempt to fullfil RestfulRegistryInterfaceReq.
>
>

Related Material

 
Changed:
<
<
Topics the authors would particularly appreciate community feedback on:
>
>
There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.
 
Changed:
<
<

Requests for discussion

>
>
There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.
 
Changed:
<
<
Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf
>
>

Requests for discussion/TODO

 
Changed:
<
<
(you're welcome to add your own...)
>
>
This is a list of questions Markus would appreciate input on. Feel free to add discussion points yourself as you see fit.
 
Changed:
<
<
  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
    • Should we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow ObsCore suggestion
>
>
Please do comment in particular if you disagree with Markus' preference.

  • Do we need rules on lowercasing values in res_detail?
    • Pro (Markus' unloved Favourite; actually, I think this is one of the few real-life TINA situations): res_details values include URIs that must be matched case-insensitively, as well as, e.g., test query fragments that must not be destroyed by futzing with case. Unless we want to force people to remember to use case-insensitive matching (I can't remember stuff like this), there's no other way.
    • Con: There's too many rules already. People can ivo_nocasematch if they look for IVORNs in res_detail
    • Alternative (Markus' Utopia): Some of us enters a time machine, goes back ten years, and stops people from declaring all kinds of things as "case-insensitive".
Added:
>
>
  • Schema name: rr, ivoa, or yet something else?
    • Proposal 1: Keep the schema name as it is (Markus' Favourite)
      • Pro: No changes necessary, it's short and easy to type
      • Con: Obscore uses the ivoa schema; it seems kinda wrong to usurp further essentially random names.
    • Proposal 2: Insinuate all ivo_% like schema names are for IVOA standardized schemas and grab ivo_rr for the relational registry
      • Pro: the schema name makes clear that this is IVOA standardized while still keeping related tables together. This will scale to future data models that might be more complex than obscore
 
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
Added:
>
>
      • Con: it's a fairly intrusive change that doesn't seem to buy a lot
    • Proposal 3: Pull all the tables into the ivoa schema
      • Pro: Consistent with obscore
      • Con: The ivoa schema will become terribly messy
  • Add strict non-null conditions (rather than and/or in addition to the milder conditions currently imposed by the shoulds on primary and foreign keys)?
    • Pro: In-DB validation might lead to less junk users have to cope with; also, non-null conditions might help implementors
    • Con (Markus' Favourite): don't require anything. What's valid is defined by VOResource anyway, but if people can ingest slightly invalid data without breaking, why punish them (by declaring them in violation of the spec)?
 
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
Changed:
<
<
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
  • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?
    • creator_seq is a different beast (it's ordered and mainly for presentation purposes; are there other places in which it's unclear if there can be hashes? -- MarkusDemleitner - 2013-03-13
      • actually there aren't, you're right. I still consider creator_seq a strange solution. -- MarcoMolinaro - 2013-03-20
  • Should we have a table mapping prefixes to namespace URI, i.e., a canoical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc? -- MarkusDemleitner - 2013-03-13

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
>
>
    • Con (Markus' Favourite): it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH. Also, there's the question of namespace management: Require namespace declarations in all records? Allow them? Forbid them?
  • Do we want creator_seq at all?
    • Pro (Markus' Favourite): Authors and author lists are, for better or worse, magic. Displaying them, and displaying them in order, is an absolute requirement for almost any UI. Not having creator_seq would imply sequence numbers in res_role and uglyfied queries, where there's indeed just this obsession to fix.
    • Con: Not in VOResource, needs logic in the ingestor. Also, since you can't predict what's in the creator fields (comma-separated list, semicolon-separated list, individual authors, something stranger yet), some author lists the ingestor creates will look odd in any case.
    • Alternative (Markus' Utopia): Change VOResource to actually mandate a certain format for creator (and atomic values). I'd still keep creator_seq, but at least its appearance would be predictable. Ah well.
  • Should we have a table mapping prefixes to namespace URI, i.e., a canoical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc?
    • Pro: clients can do schema discovery this way, FWIW; such data is necessary at least during OAI processing anyway. Also, it's a nice analog to the xmlns declaration in XML documents
    • Con: These mappings are largely static and are amended fairly slowly. Also note that it is intended that there are going to be multiple URI for a prefix (e.g., vs: already has two), so such a table is less straightforward than you may think
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)?
    • Pro: This would be particularly convenient for the res_role that, since we deviate quite a bit from VOResource, look fairly odd in the RegTAP spec.
    • Con (Markus' Favourite): Changing VOResource is a major undertaking (all registries would have to update their records), and it seems we can do without. Let's.
  • Should we keep talking about utypes? Here, there's no Markus' Favourite since I don't like any of the proposals. Also note that currently, utypes are also used in keys in res_detail. Where's Alexander the Great when you need him?
    • Pro: They are what the VO has advertised as "pointing into data models" for quite a while now. It's significant work to change the current text to make those utypes go away. There's the utype column in TAP_SCHEMA, and it'll look odd if it is empty for an IVOA-sanctioned data model (implementation). Also, the obvious alternative xpaths leads to humonguously long strings.
    • Con: The utypes tiger team has come up with a (fairly sensible) document laying out what utypes should be in the future, and they're quite different from what we propose here.
    • Con: Let's use xpaths. They're easier to understand for people with less than five years VO experience, there's no battles for their interpretation. However, the question is: Xpaths where?
      • Proposal 1: actual xpaths into instance documents
        • Pro: almost immediately usable in a wide range of implementations
Added:
>
>
        • Con: How do we represent namespaces? As prefixes? As URI? Also, these beasts will become terribly long either way
      • Proposal 2: xpaths into the schema documents, which in turn could be identified through their canonical prefixes.
        • Pro: would work quite analogous to utypes, and they may be shorter
        • Con: xpaths into XSD are plain horrible, and they won't work anyway as soon as there's two 1:1 relations in the same object of the same type (doesn't currently happen in VOResource, but anyway)
      • Proposal 3: Introduce some shorthand convention to have xpaths into instances but still allow a compact representation (but how?)
  • Should we have a validation suite?
    • Pro (Markus Favourite): No question at all; a fairly small set of representative resource records and a set of test queries alongside with their results will help a lot in validating implementations
    • Con: It's work, and quite a bit of it. But well: that just means that help is highly appreciated.
 
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"
META FILEATTACHMENT attachment="RegTAP_MySQL_schema.sql" attr="" comment="MySQL (5.6-4+) flavoured schema creation, based on 2013-03-05 draft" date="1365587018" name="RegTAP_MySQL_schema.sql" path="RegTAP_MySQL_schema.sql" size="25678" user="MarcoMolinaro" version="1"

Revision 152013-04-11 - MarcoMolinaro

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://docs.g-vo.org/ridraft (also as PDF). The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.

Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]

A script for generating the schema for MySQL servers (requires version 5.6-4 at least, due to indexing solutions) is available here. Based upon the 2013-03-05 draft it includes also example UDF functions in MySQL scripting language. (M.Molinaro - 2013-04-10)

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.

All this is an attempt to fullfil RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf

(you're welcome to add your own...)

  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
    • Should we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow ObsCore suggestion
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
  • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?
    • creator_seq is a different beast (it's ordered and mainly for presentation purposes; are there other places in which it's unclear if there can be hashes? -- MarkusDemleitner - 2013-03-13
      • actually there aren't, you're right. I still consider creator_seq a strange solution. -- MarcoMolinaro - 2013-03-20
  • Should we have a table mapping prefixes to namespace URI, i.e., a canoical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc? -- MarkusDemleitner - 2013-03-13

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
Changed:
<
<
      • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (will soon release the endpoint, give me the time to open up the firewall -- MarcoMolinaro)
>
>
 

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"
META FILEATTACHMENT attachment="RegTAP_MySQL_schema.sql" attr="" comment="MySQL (5.6-4+) flavoured schema creation, based on 2013-03-05 draft" date="1365587018" name="RegTAP_MySQL_schema.sql" path="RegTAP_MySQL_schema.sql" size="25678" user="MarcoMolinaro" version="1"

Revision 142013-04-10 - MarcoMolinaro

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://docs.g-vo.org/ridraft (also as PDF). The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.

Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]

Added:
>
>
A script for generating the schema for MySQL servers (requires version 5.6-4 at least, due to indexing solutions) is available here. Based upon the 2013-03-05 draft it includes also example UDF functions in MySQL scripting language. (M.Molinaro - 2013-04-10)
 There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.

All this is an attempt to fullfil RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf

(you're welcome to add your own...)

  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
    • Should we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow ObsCore suggestion
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
  • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?
    • creator_seq is a different beast (it's ordered and mainly for presentation purposes; are there other places in which it's unclear if there can be hashes? -- MarkusDemleitner - 2013-03-13
      • actually there aren't, you're right. I still consider creator_seq a strange solution. -- MarcoMolinaro - 2013-03-20
  • Should we have a table mapping prefixes to namespace URI, i.e., a canoical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc? -- MarkusDemleitner - 2013-03-13

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
Changed:
<
<
      • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (work in progress -- MarcoMolinaro)
>
>
      • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (will soon release the endpoint, give me the time to open up the firewall -- MarcoMolinaro)
 

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"
Added:
>
>
META FILEATTACHMENT attachment="RegTAP_MySQL_schema.sql" attr="" comment="MySQL (5.6-4+) flavoured schema creation, based on 2013-03-05 draft" date="1365587018" name="RegTAP_MySQL_schema.sql" path="RegTAP_MySQL_schema.sql" size="25678" user="MarcoMolinaro" version="1"
 

Revision 132013-03-20 - MarcoMolinaro

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://docs.g-vo.org/ridraft (also as PDF). The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.

Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.

All this is an attempt to fullfil RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf

(you're welcome to add your own...)

  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
    • Should we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow ObsCore suggestion
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
  • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?
Changed:
<
<
    • creator_seq is a different beast (it's ordered and mainly for presentation purposes; are there other places in which it's unclear if there can be hashes? -- MarkusDemleitner - 2013-03-13
      • actually there aren't, you're right. I still consider creator_seq a strange solution. What about subject.subject? VO Resource documents it as "Terms for Subject should be drawn from the IAU Astronomy
>
>
    • creator_seq is a different beast (it's ordered and mainly for presentation purposes; are there other places in which it's unclear if there can be hashes? -- MarkusDemleitner - 2013-03-13
      • actually there aren't, you're right. I still consider creator_seq a strange solution. -- MarcoMolinaro - 2013-03-20
Deleted:
<
<
Thesaurus (http://msowww.anu.edu.au/library/thesaurus/)". Do we consider it a free text keyword list? Is it better to hashtag-list it? -- MarcoMolinaro - 2013-03-20
 
  • Should we have a table mapping prefixes to namespace URI, i.e., a canoical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc? -- MarkusDemleitner - 2013-03-13

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
      • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (work in progress -- MarcoMolinaro)

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"

Revision 122013-03-20 - MarcoMolinaro

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://docs.g-vo.org/ridraft (also as PDF). The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.

Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.

All this is an attempt to fullfil RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf

(you're welcome to add your own...)

  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
    • Should we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow ObsCore suggestion
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
Changed:
<
<
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
  • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?
    • creator_seq is a different beast (it's ordered and mainly for presentation purposes; are there other places in which it's unclear if there can be hashes? -- MarkusDemleitner - 2013-03-13
>
>
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
  • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?
    • creator_seq is a different beast (it's ordered and mainly for presentation purposes; are there other places in which it's unclear if there can be hashes? -- MarkusDemleitner - 2013-03-13
Added:
>
>
      • actually there aren't, you're right. I still consider creator_seq a strange solution. What about subject.subject? VO Resource documents it as "Terms for Subject should be drawn from the IAU Astronomy Thesaurus (http://msowww.anu.edu.au/library/thesaurus/)". Do we consider it a free text keyword list? Is it better to hashtag-list it? -- MarcoMolinaro - 2013-03-20
 
  • Should we have a table mapping prefixes to namespace URI, i.e., a canoical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc? -- MarkusDemleitner - 2013-03-13

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
      • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (work in progress -- MarcoMolinaro)

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"

Revision 112013-03-13 - MarkusDemleitner

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://docs.g-vo.org/ridraft (also as PDF). The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.

Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.

All this is an attempt to fullfil RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf

(you're welcome to add your own...)

  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
    • Should we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow ObsCore suggestion
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
Changed:
<
<
    • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?
>
>
  • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?
Added:
>
>
    • creator_seq is a different beast (it's ordered and mainly for presentation purposes; are there other places in which it's unclear if there can be hashes? -- MarkusDemleitner - 2013-03-13
  • Should we have a table mapping prefixes to namespace URI, i.e., a canoical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc? -- MarkusDemleitner - 2013-03-13
 

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
      • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (work in progress -- MarcoMolinaro)

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"

Revision 102013-03-05 - MarkusDemleitner

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

Changed:
<
<
The current draft for a schema letting people query the registry via TAP
>
>
The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://docs.g-vo.org/ridraft (also as PDF). The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.
Deleted:
<
<
("RegTAP") is at http://docs.g-vo.org/ridraft (also as PDF). The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.
 
Changed:
<
<
Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16).
>
>
Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]
 
Changed:
<
<
There is a draft for a replacement of the Registry Interfaces
>
>
There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.
Deleted:
<
<
specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.
 
Changed:
<
<
There is also a rough draft on representing STC coverage information
>
>
There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.
Deleted:
<
<
alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.
  All this is an attempt to fullfil RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf

(you're welcome to add your own...)

  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
    • Should we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow ObsCore suggestion
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
    • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
      • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (work in progress -- MarcoMolinaro)

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"

Revision 92013-03-04 - MarkusDemleitner

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

Changed:
<
<
The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://volute.googlecode.com/svn/trunk/projects/registry/regtap/RegTAP-fmt.html; check out the directory this is in from volute to edit and fix things (which you're welcome to do).
>
>
The current draft for a schema letting people query the registry via TAP
Added:
>
>
("RegTAP") is at http://docs.g-vo.org/ridraft (also as PDF). The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.
  Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16).
Changed:
<
<
There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.
>
>
There is a draft for a replacement of the Registry Interfaces
Added:
>
>
specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.
 
Changed:
<
<
See also RestfulRegistryInterfaceReq.
>
>
There is also a rough draft on representing STC coverage information
Added:
>
>
alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.
 
Added:
>
>
All this is an attempt to fullfil RestfulRegistryInterfaceReq.
 Topics the authors would particularly appreciate community feedback on:

Requests for discussion

Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf

(you're welcome to add your own...)

  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
    • Should we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow ObsCore suggestion
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
Deleted:
<
<
  • Should footprint_ivoid and data_url go into res_details rather than being given a prominent place in the resource table?
 
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
    • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
      • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (work in progress -- MarcoMolinaro)

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"

Revision 82013-02-15 - MarcoMolinaro

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://volute.googlecode.com/svn/trunk/projects/registry/regtap/RegTAP-fmt.html; check out the directory this is in from volute to edit and fix things (which you're welcome to do).

Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16).

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

See also RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf

(you're welcome to add your own...)

  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
    • Should we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
Changed:
<
<
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow Obscore suggestion
      • Con: profliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
>
>
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow ObsCore suggestion
      • Con: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
 
  • Should footprint_ivoid and data_url go into res_details rather than being given a prominent place in the resource table?
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
    • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
      • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (work in progress -- MarcoMolinaro)

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"

Revision 72013-02-15 - MarcoMolinaro

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://volute.googlecode.com/svn/trunk/projects/registry/regtap/RegTAP-fmt.html; check out the directory this is in from volute to edit and fix things (which you're welcome to do).

Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16).

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

See also RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf

(you're welcome to add your own...)

  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
Changed:
<
<
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
>
>
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
Added:
>
>
    • Should we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
      • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow Obscore suggestion
      • Con: profliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
 
  • Should footprint_ivoid and data_url go into res_details rather than being given a prominent place in the resource table?
  • Should there be a required table containing VOResource XML fragments?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
Added:
>
>
  • Should we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
    • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?
 

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
Changed:
<
<
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
>
>
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
      • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (work in progress -- MarcoMolinaro)
 

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"

Revision 62013-02-11 - MarkusDemleitner

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://volute.googlecode.com/svn/trunk/projects/registry/regtap/RegTAP-fmt.html; check out the directory this is in from volute to edit and fix things (which you're welcome to do).

Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16).

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

See also RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

Added:
>
>
Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf
 (you're welcome to add your own...)
Deleted:
<
<
  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
 
  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
  • Should footprint_ivoid and data_url go into res_details rather than being given a prominent place in the resource table?
Changed:
<
<
  • Should there be a required table containing VOResource XML?
>
>
  • Should there be a required table containing VOResource XML fragments?
 
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
Changed:
<
<
  • Should the node name going into the utypes be the type of the root element (i.e., vor:standard.endorsedVersion)? In general, that's certainly a bad idea (we don't want standard.curation, service.curation, authority.curation...), but maybe it makes sense for what's, e.g., in Standard but not in Resource?
  • Do we want to require VO registries to have either day or seconds granularity (cf. http://www.openarchives.org/OAI/openarchivesprotocol.html#SelectiveHarvestingandDatestamps)?
    • Pro: It's kind of a pain to have to ask each time before harvesting.
  • Do we want to talk about STC at all?
    • If this works, it can certainly cut down on the number of services to query -- for the current VO, that would be almost a precondition to make All-VO SCS queries feasible, and with SIAP and SSAP, we may be running into such a situation sooner or later, too.
    • It's an awful lot of work, and it's not clear at all many people would use such a facility anyway.
  • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor)
>
>

Old discussion items

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
    • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
 

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"

Revision 52012-12-17 - MarkusDemleitner

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

Changed:
<
<
The current draft for a schema letting people query the registry via TAP
>
>
The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://volute.googlecode.com/svn/trunk/projects/registry/regtap/RegTAP-fmt.html; check out the directory this is in from volute to edit and fix things (which you're welcome to do).
Deleted:
<
<
("RegTAP") is at https://volute.googlecode.com/svn/trunk/projects/registry/regtap/RegTAP-fmt.html; check out the directory this is in from volute to edit and fix things (which you're welcome to do).
  Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16).
Changed:
<
<
There is a draft for a replacement of the Registry Interfaces
>
>
There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.
Deleted:
<
<
specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.
  See also RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

(you're welcome to add your own...)

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
  • Should footprint_ivoid and data_url go into res_details rather than being given a prominent place in the resource table?
  • Should there be a required table containing VOResource XML?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should the node name going into the utypes be the type of the root element (i.e., vor:standard.endorsedVersion)? In general, that's certainly a bad idea (we don't want standard.curation, service.curation, authority.curation...), but maybe it makes sense for what's, e.g., in Standard but not in Resource?
  • Do we want to require VO registries to have either day or seconds granularity (cf. http://www.openarchives.org/OAI/openarchivesprotocol.html#SelectiveHarvestingandDatestamps)?
    • Pro: It's kind of a pain to have to ask each time before harvesting.
  • Do we want to talk about STC at all?
    • If this works, it can certainly cut down on the number of services to query -- for the current VO, that would be almost a precondition to make All-VO SCS queries feasible, and with SIAP and SSAP, we may be running into such a situation sooner or later, too.
    • It's an awful lot of work, and it's not clear at all many people would use such a facility anyway.
  • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor)

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"

Revision 42012-12-12 - MarkusDemleitner

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

Changed:
<
<
There is an internal working draft at http://docs.g-vo.org/ridraft.
>
>
The current draft for a schema letting people query the registry via TAP
Added:
>
>
("RegTAP") is at https://volute.googlecode.com/svn/trunk/projects/registry/regtap/RegTAP-fmt.html; check out the directory this is in from volute to edit and fix things (which you're welcome to do).
 
Changed:
<
<
You can access and edit the draft sources in volute, http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface
>
>
Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16).
 
Changed:
<
<
Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16).
>
>
There is a draft for a replacement of the Registry Interfaces
Added:
>
>
specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.
  See also RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

(you're welcome to add your own...)

Changed:
<
<
  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
>
>
  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
 
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
  • Should footprint_ivoid and data_url go into res_details rather than being given a prominent place in the resource table?
  • Should there be a required table containing VOResource XML?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should the node name going into the utypes be the type of the root element (i.e., vor:standard.endorsedVersion)? In general, that's certainly a bad idea (we don't want standard.curation, service.curation, authority.curation...), but maybe it makes sense for what's, e.g., in Standard but not in Resource?
  • Do we want to require VO registries to have either day or seconds granularity (cf. http://www.openarchives.org/OAI/openarchivesprotocol.html#SelectiveHarvestingandDatestamps)?
    • Pro: It's kind of a pain to have to ask each time before harvesting.
  • Do we want to talk about STC at all?
    • If this works, it can certainly cut down on the number of services to query -- for the current VO, that would be almost a precondition to make All-VO SCS queries feasible, and with SIAP and SSAP, we may be running into such a situation sooner or later, too.
    • It's an awful lot of work, and it's not clear at all many people would use such a facility anyway.
  • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor)

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"

Revision 32012-11-16 - RayPlante

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

There is an internal working draft at http://docs.g-vo.org/ridraft.

You can access and edit the draft sources in volute, http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface

Added:
>
>
Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16).
 See also RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

(you're welcome to add your own...)

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
  • Should footprint_ivoid and data_url go into res_details rather than being given a prominent place in the resource table?
  • Should there be a required table containing VOResource XML?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should the node name going into the utypes be the type of the root element (i.e., vor:standard.endorsedVersion)? In general, that's certainly a bad idea (we don't want standard.curation, service.curation, authority.curation...), but maybe it makes sense for what's, e.g., in Standard but not in Resource?
  • Do we want to require VO registries to have either day or seconds granularity (cf. http://www.openarchives.org/OAI/openarchivesprotocol.html#SelectiveHarvestingandDatestamps)?
    • Pro: It's kind of a pain to have to ask each time before harvesting.
  • Do we want to talk about STC at all?
    • If this works, it can certainly cut down on the number of services to query -- for the current VO, that would be almost a precondition to make All-VO SCS queries feasible, and with SIAP and SSAP, we may be running into such a situation sooner or later, too.
    • It's an awful lot of work, and it's not clear at all many people would use such a facility anyway.
  • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor)

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->
Added:
>
>
META FILEATTACHMENT attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1"
 

Revision 22012-09-20 - MarkTaylor

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

There is an internal working draft at http://docs.g-vo.org/ridraft.

You can access and edit the draft sources in volute, http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface

See also RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

(you're welcome to add your own...)

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
Added:
>
>
    • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
 
  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
  • Should footprint_ivoid and data_url go into res_details rather than being given a prominent place in the resource table?
  • Should there be a required table containing VOResource XML?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should the node name going into the utypes be the type of the root element (i.e., vor:standard.endorsedVersion)? In general, that's certainly a bad idea (we don't want standard.curation, service.curation, authority.curation...), but maybe it makes sense for what's, e.g., in Standard but not in Resource?
  • Do we want to require VO registries to have either day or seconds granularity (cf. http://www.openarchives.org/OAI/openarchivesprotocol.html#SelectiveHarvestingandDatestamps)?
    • Pro: It's kind of a pain to have to ask each time before harvesting.
  • Do we want to talk about STC at all?
    • If this works, it can certainly cut down on the number of services to query -- for the current VO, that would be almost a precondition to make All-VO SCS queries feasible, and with SIAP and SSAP, we may be running into such a situation sooner or later, too.
    • It's an awful lot of work, and it's not clear at all many people would use such a facility anyway.
Added:
>
>
  • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor)
 

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->

Revision 12012-08-30 - MarkusDemleitner

 
META TOPICPARENT name="RelationalRegistryDM"

Discussion on Registry Interfaces Version 2

There is an internal working draft at http://docs.g-vo.org/ridraft.

You can access and edit the draft sources in volute, http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface

See also RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

(you're welcome to add your own...)

  • Is this thing just too complex to be implemented by the current workforce-strapped registries?
  • Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
    • Pro: You save between one and three tables, and it has a nice relational feel
    • Con: It's completely against VOResource; it may be a bit more inconvenient to query
  • Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
  • Should footprint_ivoid and data_url go into res_details rather than being given a prominent place in the resource table?
  • Should there be a required table containing VOResource XML?
    • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
    • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
  • Should the node name going into the utypes be the type of the root element (i.e., vor:standard.endorsedVersion)? In general, that's certainly a bad idea (we don't want standard.curation, service.curation, authority.curation...), but maybe it makes sense for what's, e.g., in Standard but not in Resource?
  • Do we want to require VO registries to have either day or seconds granularity (cf. http://www.openarchives.org/OAI/openarchivesprotocol.html#SelectiveHarvestingandDatestamps)?
    • Pro: It's kind of a pain to have to ask each time before harvesting.
  • Do we want to talk about STC at all?
    • If this works, it can certainly cut down on the number of services to query -- for the current VO, that would be almost a precondition to make All-VO SCS queries feasible, and with SIAP and SSAP, we may be running into such a situation sooner or later, too.
    • It's an awful lot of work, and it's not clear at all many people would use such a facility anyway.

Requests for contributions

  • Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
  • Who'd work with us in creating a validation suite?
<--  
-->
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback