Difference: UtypeTigerTeamMinTel4 (1 vs. 3)

Revision 32021-04-13 - GiuliaIafrate

 
META TOPICPARENT name="UtypesTigerTeam"

<--  
-->

Minutes Oct 2 2012

Pending Action Items:

- MD Explicit UC for R#9: TBC

- GL VO-URP coverage of UCs: TBC with a new wiki page

- GL Edit Usage Document: done.

- MG VOEvent, VOUnits and Utypes: TBC

Changed:
<
<
- JS PhotDM: discussion on the list, TBC by writing down the conclusions on the wiki pages (TBD which ones)
>
>
- JS PhotDMv1-1: discussion on the list, TBC by writing down the conclusions on the wiki pages (TBD which ones)
 
Changed:
<
<
Discussion Items: PhotDM, VO-URP and Use Cases, Interop.
>
>
Discussion Items: PhotDMv1-1, VO-URP and Use Cases, Interop.
 
Changed:
<
<
  • !PhotDM.
Gerard: UTypes should follow classes relationship, not instances. He is trying to represent PhotDM via VO-URP. Some relationship were tricky to understand, and he will report offline.
>
>
  • !PhotDMv1-1.
Gerard: UTypes should follow classes relationship, not instances. He is trying to represent PhotDMv1-1 via VO-URP. Some relationship were tricky to understand, and he will report offline.
  Jesus: the conclusion of the discussion seems to be that there are two options we have to choose from. Will report on the wiki pages.

  • VO-URP and Use Cases.
Gerard went through his email. Some interesting points:

- A question is which of the UCs should be addressed by Utypes and which by a description language or something else.

- (De)serialization of DMs can be faithful and lossless with some technologies (e.g. XSD/XML, Relational Model/DBMS, OOP), lossy with tabular formats.

- Some tabular formats like VOTable give more freedom of choice, more than with Object-Relational Mapping. FITS doesn't, Relational Model does.

- Omar: if the only lossless serialization is through, let's say, XML, should we require DAL services to expose XML serializations? A discussion followed:

- Pat: relational queries (i.e. TAP) don' require entire classes to be properly serialized

- Jesus: that's true, but we could move to services that respond to Object Oriented queries, thus returning proper DM serializations.

- Gerard: a similar question might be whether DAL services are requires to expose complete DM information allowing clients to deserialize complete instances [Not sure I got this right]

The discussion was heading away from the UTypes scope, so we got back on track.

- Omar: if you lose information by serializing in table formats, does that rule out the possibility of serializing DMs in terms of (key, value) pairs and as such rule out FITS?

- Gerard: each DM should define the supported formats and serialization. I expect different applications to be specialized in dealing with different DMs. I don't see a use case where you need something else.

- Omar: an outstanding case is SED: when you build aggregate SEDs you can indeed import valid spectra instances, but you also have to add photometric data from catalogs. Each catalog has a different DM that reuses the standard SpectralDM (different number of columns). How can the client handle this use case? Similarly, since STC is used by other models and hardly serialized by itself, does that mean that every DM redefines how STC gets serialized?

- [I noted down Gerard's answer, but I can't read what I wrote. Gerard, could you integrate?]

  • Data Models are graphs, not trees.
Matthew: This statement would rule out some solutions, e.g. UTypes are not unique identifiers (you can navigate to a class following different paths) and can't work as simple pointers; they can't be thought as similar to XPATH.

-- MireilleLouys - 2012 Oct 05

My understanding is slightly different: because data models are graphs , not always entirely covered by a tree superimposed structure, Xpath is not the universal tool to provide a unique path to every single datamodel item.However, a UML class diagram , usually does not allow cycles, so a minimal spanning tree should be possible to build.

Following the requirements a data model is built for, I guess several objects can be identified as "main" or "root" objects, providing non-overlapping sub-trees. So a unique path should be possibly defined , relying on Xpath for the various tree components. See example for Phot DM at [[][]].

-- MireilleLouys - 2012 Oct 05

- Pat: other requirements fall out of what's allowed for UTypes, e.g. case sensitivity: UTypes are case sensitive if the DM is case sensitive.

- Gerard: It depends. For instance, if UTypes are non-parseable labels and they just point to a DM element, then it's not true.

  • Interop.
There will be two sessions for UTypes. The first is a plenary session for the Tiger Team to report back. Omar will chair the session. We are going to have three talks:

- Matthew: report on Usages Document 20'

- Omar: report on use cases and their analysis 20'

- Gerard (remotely or channeling through Markus): VO-URP coverage of UCs 20'

The second session will be parallel and for discussion: it can be a spillover of the plenary questions and discussion. Omar is going to collect few slides to feed the discussion, which is expected to be open anyway.

Example discussion point (slide):

- What are UTypes for? (Gerard)

  • Action Items:
- MD Explicit UC for R#9

- GL VO-URP coverage of UCs

Changed:
<
<
- GL PhotDM description via VO-URP
>
>
- GL PhotDMv1-1 description via VO-URP
  - MG VOEvent, VOUnits and Utypes: TBC
Changed:
<
<
- JS PhotDM discussion's conclusions on wiki page
>
>
- JS PhotDMv1-1 discussion's conclusions on wiki page
  - All provide discussion points for UTypes parallel session (write them to Omar and Jesus)

We are going to meet next week, same day same time.

Revision 22012-10-05 - MireilleLouys

 
META TOPICPARENT name="UtypesTigerTeam"

<--  
-->

Minutes Oct 2 2012

Pending Action Items:

Changed:
<
<
- MD Explicit UC for R#9: TBC
>
>
- MD Explicit UC for R#9: TBC
 
Changed:
<
<
- GL VO-URP coverage of UCs: TBC with a new wiki page
>
>
- GL VO-URP coverage of UCs: TBC with a new wiki page
 
Changed:
<
<
- GL Edit Usage Document: done.
>
>
- GL Edit Usage Document: done.
 
Changed:
<
<
- MG VOEvent, VOUnits and Utypes: TBC
>
>
- MG VOEvent, VOUnits and Utypes: TBC
 
Changed:
<
<
- JS PhotDM: discussion on the list, TBC by writing down the conclusions on the wiki pages (TBD which ones)
>
>
- JS PhotDM: discussion on the list, TBC by writing down the conclusions on the wiki pages (TBD which ones)
 
Changed:
<
<
Discussion Items:
>
>
Discussion Items: PhotDM, VO-URP and Use Cases, Interop.
 
Changed:
<
<
- PhotDM
>
>
  • !PhotDM.
Deleted:
<
<
- VO-URP and Use Cases

- Interop

PhotDM.

 Gerard: UTypes should follow classes relationship, not instances. He is trying to represent PhotDM via VO-URP. Some relationship were tricky to understand, and he will report offline.

Jesus: the conclusion of the discussion seems to be that there are two options we have to choose from. Will report on the wiki pages.

Changed:
<
<
VO-URP and Use Cases.
>
>
  • VO-URP and Use Cases.
Deleted:
<
<
 Gerard went through his email. Some interesting points:
Changed:
<
<
- A question is which of the UCs should be addressed by Utypes and which by a description language or something else.
>
>
- A question is which of the UCs should be addressed by Utypes and which by a description language or something else.
 
Changed:
<
<
- (De)serialization of DMs can be faithful and lossless with some technologies (e.g. XSD/XML, Relational Model/DBMS, OOP), lossy with tabular formats.
>
>
- (De)serialization of DMs can be faithful and lossless with some technologies (e.g. XSD/XML, Relational Model/DBMS, OOP), lossy with tabular formats.
 
Changed:
<
<
- Some tabular formats like VOTable give more freedom of choice, more than with Object-Relational Mapping. FITS doesn't, Relational Model does.
>
>
- Some tabular formats like VOTable give more freedom of choice, more than with Object-Relational Mapping. FITS doesn't, Relational Model does.
 
Changed:
<
<
- Omar: if the only lossless serialization is through, let's say, XML, should we require DAL services to expose XML serializations? A discussion followed:
>
>
- Omar: if the only lossless serialization is through, let's say, XML, should we require DAL services to expose XML serializations? A discussion followed:
 
Changed:
<
<
- Pat: relational queries (i.e. TAP) don' require entire classes to be properly serialized
>
>
- Pat: relational queries (i.e. TAP) don' require entire classes to be properly serialized
 
Changed:
<
<
- Jesus: that's true, but we could move to services that respond to Object Oriented queries, thus returning proper DM serializations.
>
>
- Jesus: that's true, but we could move to services that respond to Object Oriented queries, thus returning proper DM serializations.
 
Changed:
<
<
- Gerard: a similar question might be whether DAL services are requires to expose complete DM information allowing clients to deserialize complete instances [Not sure I got this right]
>
>
- Gerard: a similar question might be whether DAL services are requires to expose complete DM information allowing clients to deserialize complete instances [Not sure I got this right]
  The discussion was heading away from the UTypes scope, so we got back on track.
Changed:
<
<
- Omar: if you lose information by serializing in table formats, does that rule out the possibility of serializing DMs in terms of (key, value) pairs and as such rule out FITS?
>
>
- Omar: if you lose information by serializing in table formats, does that rule out the possibility of serializing DMs in terms of (key, value) pairs and as such rule out FITS?
 
Changed:
<
<
- Gerard: each DM should define the supported formats and serialization. I expect different applications to be specialized in dealing with different DMs. I don't see a use case where you need something else.
>
>
- Gerard: each DM should define the supported formats and serialization. I expect different applications to be specialized in dealing with different DMs. I don't see a use case where you need something else.
 
Changed:
<
<
- Omar: an outstanding case is SED: when you build aggregate SEDs you can indeed import valid spectra instances, but you also have to add photometric data from catalogs. Each catalog has a different DM that reuses the standard SpectralDM (different number of columns). How can the client handle this use case? Similarly, since STC is used by other models and hardly serialized by itself, does that mean that every DM redefines how STC gets serialized?
>
>
- Omar: an outstanding case is SED: when you build aggregate SEDs you can indeed import valid spectra instances, but you also have to add photometric data from catalogs. Each catalog has a different DM that reuses the standard SpectralDM (different number of columns). How can the client handle this use case? Similarly, since STC is used by other models and hardly serialized by itself, does that mean that every DM redefines how STC gets serialized?
 
Changed:
<
<
- [I noted down Gerard's answer, but I can't read what I wrote. Gerard, could you integrate?]
>
>
- [I noted down Gerard's answer, but I can't read what I wrote. Gerard, could you integrate?]
 
Changed:
<
<
- Data Models are graphs, not trees.
>
>
  • Data Models are graphs, not trees.
Added:
>
>
Matthew: This statement would rule out some solutions, e.g. UTypes are not unique identifiers (you can navigate to a class following different paths) and can't work as simple pointers; they can't be thought as similar to XPATH.
 
Changed:
<
<
- Matthew: This statement would rule out some solutions, e.g. UTypes are not unique identifiers (you can navigate to a class following different paths) and can't work as simple pointers; they can't be thought as similar to XPATH.
>
>
-- MireilleLouys - 2012 Oct 05
 
Changed:
<
<
- Pat: other requirements fall out of what's allowed for UTypes, e.g. case sensitivity: UTypes are case sensitive if the DM is case sensitive.
>
>
My understanding is slightly different: because data models are graphs , not always entirely covered by a tree superimposed structure, Xpath is not the universal tool to provide a unique path to every single datamodel item.However, a UML class diagram , usually does not allow cycles, so a minimal spanning tree should be possible to build.
 
Changed:
<
<
- Gerard: It depends. For instance, if UTypes are non-parseable labels and they just point to a DM element, then it's not true.
>
>
Following the requirements a data model is built for, I guess several objects can be identified as "main" or "root" objects, providing non-overlapping sub-trees. So a unique path should be possibly defined , relying on Xpath for the various tree components. See example for Phot DM at [[][]].
 
Changed:
<
<
Interop.
>
>
-- MireilleLouys - 2012 Oct 05
 
Added:
>
>
- Pat: other requirements fall out of what's allowed for UTypes, e.g. case sensitivity: UTypes are case sensitive if the DM is case sensitive.

- Gerard: It depends. For instance, if UTypes are non-parseable labels and they just point to a DM element, then it's not true.

  • Interop.
 There will be two sessions for UTypes. The first is a plenary session for the Tiger Team to report back. Omar will chair the session. We are going to have three talks:
Changed:
<
<
- Matthew: report on Usages Document 20'
>
>
- Matthew: report on Usages Document 20'
 
Changed:
<
<
- Omar: report on use cases and their analysis 20'
>
>
- Omar: report on use cases and their analysis 20'
 
Changed:
<
<
- Gerard (remotely or channeling through Markus): VO-URP coverage of UCs 20'
>
>
- Gerard (remotely or channeling through Markus): VO-URP coverage of UCs 20'
  The second session will be parallel and for discussion: it can be a spillover of the plenary questions and discussion. Omar is going to collect few slides to feed the discussion, which is expected to be open anyway.

Example discussion point (slide):

Changed:
<
<
- What are UTypes for? (Gerard)
>
>
- What are UTypes for? (Gerard)
 
Changed:
<
<
Action Items:
>
>
  • Action Items:
Added:
>
>
- MD Explicit UC for R#9
 
Changed:
<
<
- MD Explicit UC for R#9
>
>
- GL VO-URP coverage of UCs
 
Changed:
<
<
- GL VO-URP coverage of UCs
>
>
- GL PhotDM description via VO-URP
 
Changed:
<
<
- GL PhotDM description via VO-URP
>
>
- MG VOEvent, VOUnits and Utypes: TBC
 
Changed:
<
<
- MG VOEvent, VOUnits and Utypes: TBC
>
>
- JS PhotDM discussion's conclusions on wiki page
 
Changed:
<
<
- JS PhotDM discussion's conclusions on wiki page
>
>
- All provide discussion points for UTypes parallel session (write them to Omar and Jesus)
Deleted:
<
<
- All provide discussion points for UTypes parallel session (write them to Omar and Jesus)
  We are going to meet next week, same day same time.

Revision 12012-10-03 - OmarLaurino

 
META TOPICPARENT name="UtypesTigerTeam"

<--  
-->

Minutes Oct 2 2012

Pending Action Items:

- MD Explicit UC for R#9: TBC

- GL VO-URP coverage of UCs: TBC with a new wiki page

- GL Edit Usage Document: done.

- MG VOEvent, VOUnits and Utypes: TBC

- JS PhotDM: discussion on the list, TBC by writing down the conclusions on the wiki pages (TBD which ones)

Discussion Items:

- PhotDM

- VO-URP and Use Cases

- Interop

PhotDM.

Gerard: UTypes should follow classes relationship, not instances. He is trying to represent PhotDM via VO-URP. Some relationship were tricky to understand, and he will report offline.

Jesus: the conclusion of the discussion seems to be that there are two options we have to choose from. Will report on the wiki pages.

VO-URP and Use Cases.

Gerard went through his email. Some interesting points:

- A question is which of the UCs should be addressed by Utypes and which by a description language or something else.

- (De)serialization of DMs can be faithful and lossless with some technologies (e.g. XSD/XML, Relational Model/DBMS, OOP), lossy with tabular formats.

- Some tabular formats like VOTable give more freedom of choice, more than with Object-Relational Mapping. FITS doesn't, Relational Model does.

- Omar: if the only lossless serialization is through, let's say, XML, should we require DAL services to expose XML serializations? A discussion followed:

- Pat: relational queries (i.e. TAP) don' require entire classes to be properly serialized

- Jesus: that's true, but we could move to services that respond to Object Oriented queries, thus returning proper DM serializations.

- Gerard: a similar question might be whether DAL services are requires to expose complete DM information allowing clients to deserialize complete instances [Not sure I got this right]

The discussion was heading away from the UTypes scope, so we got back on track.

- Omar: if you lose information by serializing in table formats, does that rule out the possibility of serializing DMs in terms of (key, value) pairs and as such rule out FITS?

- Gerard: each DM should define the supported formats and serialization. I expect different applications to be specialized in dealing with different DMs. I don't see a use case where you need something else.

- Omar: an outstanding case is SED: when you build aggregate SEDs you can indeed import valid spectra instances, but you also have to add photometric data from catalogs. Each catalog has a different DM that reuses the standard SpectralDM (different number of columns). How can the client handle this use case? Similarly, since STC is used by other models and hardly serialized by itself, does that mean that every DM redefines how STC gets serialized?

- [I noted down Gerard's answer, but I can't read what I wrote. Gerard, could you integrate?]

- Data Models are graphs, not trees.

- Matthew: This statement would rule out some solutions, e.g. UTypes are not unique identifiers (you can navigate to a class following different paths) and can't work as simple pointers; they can't be thought as similar to XPATH.

- Pat: other requirements fall out of what's allowed for UTypes, e.g. case sensitivity: UTypes are case sensitive if the DM is case sensitive.

- Gerard: It depends. For instance, if UTypes are non-parseable labels and they just point to a DM element, then it's not true.

Interop.

There will be two sessions for UTypes. The first is a plenary session for the Tiger Team to report back. Omar will chair the session. We are going to have three talks:

- Matthew: report on Usages Document 20'

- Omar: report on use cases and their analysis 20'

- Gerard (remotely or channeling through Markus): VO-URP coverage of UCs 20'

The second session will be parallel and for discussion: it can be a spillover of the plenary questions and discussion. Omar is going to collect few slides to feed the discussion, which is expected to be open anyway.

Example discussion point (slide):

- What are UTypes for? (Gerard)

Action Items:

- MD Explicit UC for R#9

- GL VO-URP coverage of UCs

- GL PhotDM description via VO-URP

- MG VOEvent, VOUnits and Utypes: TBC

- JS PhotDM discussion's conclusions on wiki page

- All provide discussion points for UTypes parallel session (write them to Omar and Jesus)

We are going to meet next week, same day same time.

 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback