InterOpMay2005 VOEvent

Participants

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk (.ppt)
• VOEvent version 0.90 draft specification (.pdf)

From the main VOEvent session,

Notes from Meeting

Alasdair Allan

• Argues for simplicity as foremost concern
• VOEvent principal tags
  • Citations
    • Follow-up to previous event
    • Supersede previous event
    • Retract previous event
    • Combine multiple events into single thread or split single event into multiple threads
  • Curation
    • Publisher ID
    • Date
  • What
    • What was observed? Burst? Flare? Dimming?
  • Where and When
    • Location in the sky (if known) and occurrence
    • Any legal STC expression
    • Try to keep concise
  • How
    • Instrument and observing conditions
  • Hypothesis
    • Supposition about the physical nature of the event
    • Natural language
    • UCDs?
    • Replace with “Why”?
  • Description

or empty except for a Reference which can,

• Can point to other event
• Allows event to be extremely terse

Finally, each VOEvent packet has a unique ID and there are multiple VOEvent “registries” (not to be confused with resource registries)

Implementation

• Transport methods
  • Primary end-user is a computer program
• System architecture
  • Hierarchical system? Or peer-to-peer?
• VOEvent Registries
  • Central database?
  • Or packets held by publisher?
  • These are not VO Resource Registries!!
• Publishers
  • Centralized or distributed?
  • Distinguish roles of Creator and Publisher… Creator can also be Publisher of its own events, but need not be
  • Publisher must guarantee persistence/permanence of event record
• Subscription
  • Subscribers create a query and lodge it with a VOEvent database (aggregator)
  • Again, centralized vs. distributed?
  • RSS model (Really Simply Syndication) http://blogs.law.harvard.edu/tech/rss
  • Is harvesting mechanism appropriate for rapid response? Different event types have different levels of time criticality. Should there be a VOEvent-Lite for the most time critical science applications? Or split into two events, first of which is simple notice (special event type) and second of which provides further information via Citation and Reference mechanisms.

• Searching
  • Queries supported against VOEvent database. Concerns about centralization and hierarchy in which there are single points of failure.
  • Or peer-to-peer via aggregators.

How many event providers vs. how many event consumers? A few providers will provide most events. Consumers will need to filter out only those events of interest to them.

Can have rich grammar without using it all for every event.

With many publishers, how does a consumer know whom to trust? As now… consumers know providers. Does this pick up on VO security models for authentication and authorization? Anticipate need to protect against imposter event publishers, for example.

Can VOEvent standard move forward without too much concern about implementation and architecture?

Some events are based on predictions. Do these fit into this paradigm? For example, solar system events, eclipses, occultations, transits, events downstream from solar flare. Should be simple to add Prediction to Hypothesis.Classification? Or in VOEvent.Role? (test, actual, prediction).

Is there a place to express expected duration of event, or the equivalent of urgency? Add to Hypothesis? “Time to live”?

Arnold Rots

• Curation
  • Handling of proprietary data; authorization
  • Syntax of VOEvent Identifiers
  • Who will provide the VOEvent repositories/databases? How are event databases retained if a publisher goes out of business?
  • How long should records be retained?
• Content requirements
  • How much information is enough?
  • User needs should determine requirements. Anticipate uses beyond those of original publishers.
  • Provide sufficient information to allow coordinate transformations. Observatory location (esp. for space-based observations).
• Data issues
  • Sensitivity of observations, detection limits
  • Linked data objects
  • Classification of event types; ontology?
• Harvesting and distribution
  • Trusted contributors? Or a free-for-all?
  • Authentication? contributors, clients?
  • Broadcasting versus querying; broker services
  • Subscription parameters: keeping the volume down
  • Estimated volume (for a given subscription…how much stuff will someone want?)
• Services
  • Auxiliary services
    • Databases of known objects - moving objects, transients, etc.
    • Name resolvers
  • Query services
    • Sophistication of queries (e.g., asteroids with a > 15 au) [ancillary service]

Sebastien Derriere

• UCDs provide semantic meaning of a quantity
• Provide flexibility
• Could use UCDs in VOEvent What element. Use and elements like in VOTable. For example, describe magnitude of event and observing conditions (seeing).
• Could use UCDs in Hypothesis element, though the mappings here are less obvious. src.class and meta.id.assoc.
• Extend UCDs to standardize the expression of enumerated values? Astronomical object types, astronomical phenomena.
• Should VOEvent be the catalyst for developing an IVOA standard vocabulary, or ontology, for astronomical objects and events? If so, at what level of granularity? Journal keywords, IAU thesaurus, SIMBAD object types…
• Alternate approach is to characterize type of light curve and use that as indicator of event type.
• Use IAU Thesaurus terms/keywords. Journal keywords? Several people at VOEvent workshop pushed for ontology approach. But folks here are concerned that this would hold up VOEvent protocol for a potentially very long time.
• Pragmatic approach might be to analyze event databases and find the most common event types, then agree on standard representations for these. Groups want to start using VOEvent protocol within the next month or two; cannot wait.

Discussion

Should consider promoting RTML through the IVOA standards process.

Authentication: consider adding authentication element of some sort to make sure VOEvent notifications come from trusted sources. Should use same mechanisms as other A&A approaches in IVOA.

Interfaces with other WGs:

• Registry for registering VOEvent publishers (but NOT VOEvents!)
• VOQL for SkyNode i/f’s to VOEvent databases

Joint Session with UCD Working Group

• Summary of the result of discussions on UCDs that took place during yesterday's VOEvent Session.

• Allow a 6 months period for the definition of a list of standard expressions used by the VOEvent producers.

• Discuss possible changes to the schema about the content of the <Hypothesis> schema within the VOEvent-core mailing list after this meeting.

InterOpMay2005 VOEvent

Participants

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk (.ppt)
• VOEvent version 0.90 draft specification (.pdf)

From the main VOEvent session,

• VOEvent: keeping it simple (.ppt) - AlasdairAllan
• VOEvent and UCDs (.pdf) - SebastienDerriere
• Open Issues for VOEvent (.ppt) - ArnoldRots

From the joint session with the UCD working group,

• VOEvent and UCDs (.ppt) - AlasdairAllan

From the final plenary session,

• Final summary (.ppt) - NicholasWalton

Notes from Meeting

Alasdair Allan

• Argues for simplicity as foremost concern
• VOEvent principal tags
  • Citations
    • Follow-up to previous event
    • Supersede previous event
    • Retract previous event
    • Combine multiple events into single thread or split single event into multiple threads
  • Curation
    • Publisher ID
    • Date
  • What
    • What was observed? Burst? Flare? Dimming?
  • Where and When
    • Location in the sky (if known) and occurrence
    • Any legal STC expression
    • Try to keep concise
  • How
    • Instrument and observing conditions
  • Hypothesis
    • Supposition about the physical nature of the event
    • Natural language
    • UCDs?
    • Replace with “Why”?
  • Description

or empty except for a Reference which can,

• Can point to other event
• Allows event to be extremely terse

Finally, each VOEvent packet has a unique ID and there are multiple VOEvent “registries” (not to be confused with resource registries)

Implementation

• Transport methods
  • Primary end-user is a computer program
• System architecture
  • Hierarchical system? Or peer-to-peer?
• VOEvent Registries
  • Central database?
  • Or packets held by publisher?
  • These are not VO Resource Registries!!
• Publishers
  • Centralized or distributed?
  • Distinguish roles of Creator and Publisher… Creator can also be Publisher of its own events, but need not be
  • Publisher must guarantee persistence/permanence of event record
• Subscription
  • Subscribers create a query and lodge it with a VOEvent database (aggregator)
  • Again, centralized vs. distributed?
  • RSS model (Really Simply Syndication) http://blogs.law.harvard.edu/tech/rss
  • Is harvesting mechanism appropriate for rapid response? Different event types have different levels of time criticality. Should there be a VOEvent-Lite for the most time critical science applications? Or split into two events, first of which is simple notice (special event type) and second of which provides further information via Citation and Reference mechanisms.

• Searching
  • Queries supported against VOEvent database. Concerns about centralization and hierarchy in which there are single points of failure.
  • Or peer-to-peer via aggregators.

How many event providers vs. how many event consumers? A few providers will provide most events. Consumers will need to filter out only those events of interest to them.

Can have rich grammar without using it all for every event.

With many publishers, how does a consumer know whom to trust? As now… consumers know providers. Does this pick up on VO security models for authentication and authorization? Anticipate need to protect against imposter event publishers, for example.

Can VOEvent standard move forward without too much concern about implementation and architecture?

Some events are based on predictions. Do these fit into this paradigm? For example, solar system events, eclipses, occultations, transits, events downstream from solar flare. Should be simple to add Prediction to Hypothesis.Classification? Or in VOEvent.Role? (test, actual, prediction).

Is there a place to express expected duration of event, or the equivalent of urgency? Add to Hypothesis? “Time to live”?

Arnold Rots

• Curation
  • Handling of proprietary data; authorization
  • Syntax of VOEvent Identifiers
  • Who will provide the VOEvent repositories/databases? How are event databases retained if a publisher goes out of business?
  • How long should records be retained?
• Content requirements
  • How much information is enough?
  • User needs should determine requirements. Anticipate uses beyond those of original publishers.
  • Provide sufficient information to allow coordinate transformations. Observatory location (esp. for space-based observations).
• Data issues
  • Sensitivity of observations, detection limits
  • Linked data objects
  • Classification of event types; ontology?
• Harvesting and distribution
  • Trusted contributors? Or a free-for-all?
  • Authentication? contributors, clients?
  • Broadcasting versus querying; broker services
  • Subscription parameters: keeping the volume down
  • Estimated volume (for a given subscription…how much stuff will someone want?)
• Services
  • Auxiliary services
    • Databases of known objects - moving objects, transients, etc.
    • Name resolvers
  • Query services
    • Sophistication of queries (e.g., asteroids with a > 15 au) [ancillary service]

Sebastien Derriere

• UCDs provide semantic meaning of a quantity
• Provide flexibility
• Could use UCDs in VOEvent What element. Use and elements like in VOTable. For example, describe magnitude of event and observing conditions (seeing).
• Could use UCDs in Hypothesis element, though the mappings here are less obvious. src.class and meta.id.assoc.
• Extend UCDs to standardize the expression of enumerated values? Astronomical object types, astronomical phenomena.
• Should VOEvent be the catalyst for developing an IVOA standard vocabulary, or ontology, for astronomical objects and events? If so, at what level of granularity? Journal keywords, IAU thesaurus, SIMBAD object types…
• Alternate approach is to characterize type of light curve and use that as indicator of event type.
• Use IAU Thesaurus terms/keywords. Journal keywords? Several people at VOEvent workshop pushed for ontology approach. But folks here are concerned that this would hold up VOEvent protocol for a potentially very long time.
• Pragmatic approach might be to analyze event databases and find the most common event types, then agree on standard representations for these. Groups want to start using VOEvent protocol within the next month or two; cannot wait.

Discussion

Should consider promoting RTML through the IVOA standards process.

Authentication: consider adding authentication element of some sort to make sure VOEvent notifications come from trusted sources. Should use same mechanisms as other A&A approaches in IVOA.

Interfaces with other WGs:

• Registry for registering VOEvent publishers (but NOT VOEvents!)

Joint Session with UCD Working Group

• Summary of the result of discussions on UCDs that took place during yesterday's VOEvent Session.

• Allow a 6 months period for the definition of a list of standard expressions used by the VOEvent producers.

• Discuss possible changes to the schema about the content of the <Hypothesis> schema within the VOEvent-core mailing list after this meeting.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk (.ppt)
• VOEvent version 0.90 draft specification (.pdf)

From the main VOEvent session,

• VOEvent: keeping it simple (.ppt) - AlasdairAllan
• VOEvent and UCDs (.pdf) - SebastienDerriere
• Open Issues for VOEvent (.ppt) - ArnoldRots

From the joint session with the UCD working group,

• VOEvent and UCDs (.ppt) - AlasdairAllan

From the final plenary session,

• Final summary (.ppt) - NicholasWalton

Notes from Meeting

Alasdair Allan

• Argues for simplicity as foremost concern
• VOEvent principal tags
  • Citations
    • Follow-up to previous event
    • Supersede previous event
    • Retract previous event
    • Combine multiple events into single thread or split single event into multiple threads
  • Curation
    • Publisher ID
    • Date
  • What
    • What was observed? Burst? Flare? Dimming?
  • Where and When
    • Location in the sky (if known) and occurrence
    • Any legal STC expression
    • Try to keep concise
  • How
    • Instrument and observing conditions
  • Hypothesis
    • Supposition about the physical nature of the event
    • Natural language
    • UCDs?
    • Replace with “Why”?
  • Description

or empty except for a Reference which can,

• Can point to other event
• Allows event to be extremely terse

Finally, each VOEvent packet has a unique ID and there are multiple VOEvent “registries” (not to be confused with resource registries)

Implementation

• Transport methods
  • Primary end-user is a computer program
• System architecture
  • Hierarchical system? Or peer-to-peer?
• VOEvent Registries
  • Central database?
  • Or packets held by publisher?
  • These are not VO Resource Registries!!
• Publishers
  • Centralized or distributed?
  • Distinguish roles of Creator and Publisher… Creator can also be Publisher of its own events, but need not be
  • Publisher must guarantee persistence/permanence of event record
• Subscription
  • Subscribers create a query and lodge it with a VOEvent database (aggregator)
  • Again, centralized vs. distributed?
  • RSS model (Really Simply Syndication) http://blogs.law.harvard.edu/tech/rss
  • Is harvesting mechanism appropriate for rapid response? Different event types have different levels of time criticality. Should there be a VOEvent-Lite for the most time critical science applications? Or split into two events, first of which is simple notice (special event type) and second of which provides further information via Citation and Reference mechanisms.

• Searching
  • Queries supported against VOEvent database. Concerns about centralization and hierarchy in which there are single points of failure.
  • Or peer-to-peer via aggregators.

How many event providers vs. how many event consumers? A few providers will provide most events. Consumers will need to filter out only those events of interest to them.

Can have rich grammar without using it all for every event.

With many publishers, how does a consumer know whom to trust? As now… consumers know providers. Does this pick up on VO security models for authentication and authorization? Anticipate need to protect against imposter event publishers, for example.

Can VOEvent standard move forward without too much concern about implementation and architecture?

Some events are based on predictions. Do these fit into this paradigm? For example, solar system events, eclipses, occultations, transits, events downstream from solar flare. Should be simple to add Prediction to Hypothesis.Classification? Or in VOEvent.Role? (test, actual, prediction).

Is there a place to express expected duration of event, or the equivalent of urgency? Add to Hypothesis? “Time to live”?

Arnold Rots

• Curation
  • Handling of proprietary data; authorization
  • Syntax of VOEvent Identifiers
  • Who will provide the VOEvent repositories/databases? How are event databases retained if a publisher goes out of business?
  • How long should records be retained?
• Content requirements
  • How much information is enough?
  • User needs should determine requirements. Anticipate uses beyond those of original publishers.
  • Provide sufficient information to allow coordinate transformations. Observatory location (esp. for space-based observations).
• Data issues
  • Sensitivity of observations, detection limits
  • Linked data objects
  • Classification of event types; ontology?
• Harvesting and distribution
  • Trusted contributors? Or a free-for-all?
  • Authentication? contributors, clients?
  • Broadcasting versus querying; broker services
  • Subscription parameters: keeping the volume down
  • Estimated volume (for a given subscription…how much stuff will someone want?)
• Services
  • Auxiliary services
    • Databases of known objects - moving objects, transients, etc.
    • Name resolvers
  • Query services
    • Sophistication of queries (e.g., asteroids with a > 15 au) [ancillary service]

Sebastien Derriere

• UCDs provide semantic meaning of a quantity
• Provide flexibility
• Could use UCDs in VOEvent What element. Use and elements like in VOTable. For example, describe magnitude of event and observing conditions (seeing).
• Could use UCDs in Hypothesis element, though the mappings here are less obvious. src.class and meta.id.assoc.
• Extend UCDs to standardize the expression of enumerated values? Astronomical object types, astronomical phenomena.
• Should VOEvent be the catalyst for developing an IVOA standard vocabulary, or ontology, for astronomical objects and events? If so, at what level of granularity? Journal keywords, IAU thesaurus, SIMBAD object types…
• Alternate approach is to characterize type of light curve and use that as indicator of event type.
• Use IAU Thesaurus terms/keywords. Journal keywords? Several people at VOEvent workshop pushed for ontology approach. But folks here are concerned that this would hold up VOEvent protocol for a potentially very long time.
• Pragmatic approach might be to analyze event databases and find the most common event types, then agree on standard representations for these. Groups want to start using VOEvent protocol within the next month or two; cannot wait.

Discussion

Should consider promoting RTML through the IVOA standards process.

Authentication: consider adding authentication element of some sort to make sure VOEvent notifications come from trusted sources. Should use same mechanisms as other A&A approaches in IVOA.

Interfaces with other WGs:

• Registry for registering VOEvent publishers (but NOT VOEvents!)
• VOQL for SkyNode i/f’s to VOEvent databases

Joint Session with UCD Working Group

• Summary of the result of discussions on UCDs that took place during yesterday's VOEvent Session.

• Allow a 6 months period for the definition of a list of standard expressions used by the VOEvent producers.

• Discuss possible changes to the schema about the content of the <Hypothesis> schema within the VOEvent-core mailing list after this meeting.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

• BobHanisch (stand-in session chair)
• Approx. 14 people attending

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk (.ppt)
• VOEvent version 0.90 draft specification (.pdf)

• VOEvent: keeping it simple (.ppt) - AlasdairAllan
• VOEvent and UCDs (.pdf) - SebastienDerriere
• Open Issues for VOEvent (.ppt) - ArnoldRots

From the joint session with the UCD working group,

• VOEvent and UCDs (.ppt) - AlasdairAllan

Notes from Meeting

VOEvent Session, Thursday 9am

Alasdair Allan

Messages

• Argues for simplicity as foremost concern
• VOEvent principal tags
  • Citations
    • Follow-up to previous event
    • Supersede previous event
    • Retract previous event
    • Combine multiple events into single thread or split single event into multiple threads
  • Curation
    • Publisher ID
    • Date
  • What
    • What was observed? Burst? Flare? Dimming?
  • Where and When
    • Location in the sky (if known) and occurrence
    • Any legal STC expression
    • Try to keep concise
  • How
    • Instrument and observing conditions
  • Hypothesis
    • Supposition about the physical nature of the event
    • Natural language
    • UCDs?
    • Replace with “Why”?
  • Description

or empty except for a Reference which can,

• Can point to other event
• Allows event to be extremely terse

Finally, each VOEvent packet has a unique ID and there are multiple VOEvent “registries” (not to be confused with resource registries)

Implementation

• Transport methods
  • Primary end-user is a computer program
• System architecture
  • Hierarchical system? Or peer-to-peer?
• VOEvent Registries
  • Central database?
  • Or packets held by publisher?
  • These are not VO Resource Registries!!
• Publishers
  • Centralized or distributed?
  • Distinguish roles of Creator and Publisher… Creator can also be Publisher of its own events, but need not be
  • Publisher must guarantee persistence/permanence of event record
• Subscription
  • Subscribers create a query and lodge it with a VOEvent database (aggregator)
  • Again, centralized vs. distributed?
  • RSS model (Really Simply Syndication) http://blogs.law.harvard.edu/tech/rss
  • Is harvesting mechanism appropriate for rapid response? Different event types have different levels of time criticality. Should there be a VOEvent-Lite for the most time critical science applications? Or split into two events, first of which is simple notice (special event type) and second of which provides further information via Citation and Reference mechanisms.

• Searching
  • Queries supported against VOEvent database. Concerns about centralization and hierarchy in which there are single points of failure.
  • Or peer-to-peer via aggregators.

How many event providers vs. how many event consumers? A few providers will provide most events. Consumers will need to filter out only those events of interest to them.

Can have rich grammar without using it all for every event.

With many publishers, how does a consumer know whom to trust? As now… consumers know providers. Does this pick up on VO security models for authentication and authorization? Anticipate need to protect against imposter event publishers, for example.

Can VOEvent standard move forward without too much concern about implementation and architecture?

Some events are based on predictions. Do these fit into this paradigm? For example, solar system events, eclipses, occultations, transits, events downstream from solar flare. Should be simple to add Prediction to Hypothesis.Classification? Or in VOEvent.Role? (test, actual, prediction).

Is there a place to express expected duration of event, or the equivalent of urgency? Add to Hypothesis? “Time to live”?

Arnold Rots

Open issues include

• Curation
  • Handling of proprietary data; authorization
  • Syntax of VOEvent Identifiers
  • Who will provide the VOEvent repositories/databases? How are event databases retained if a publisher goes out of business?
  • How long should records be retained?
• Content requirements
  • How much information is enough?
  • User needs should determine requirements. Anticipate uses beyond those of original publishers.
  • Provide sufficient information to allow coordinate transformations. Observatory location (esp. for space-based observations).
• Data issues
  • Sensitivity of observations, detection limits
  • Linked data objects
  • Classification of event types; ontology?
• Harvesting and distribution
  • Trusted contributors? Or a free-for-all?
  • Authentication? contributors, clients?
  • Broadcasting versus querying; broker services
  • Subscription parameters: keeping the volume down
  • Estimated volume (for a given subscription…how much stuff will someone want?)
• Services
  • Auxiliary services
    • Databases of known objects - moving objects, transients, etc.
    • Name resolvers
  • Query services
    • Sophistication of queries (e.g., asteroids with a > 15 au) [ancillary service]

Sebastien Derriere

VOEvent and UCDs

• UCDs provide semantic meaning of a quantity
• Provide flexibility
• Could use UCDs in VOEvent What element. Use and elements like in VOTable. For example, describe magnitude of event and observing conditions (seeing).
• Could use UCDs in Hypothesis element, though the mappings here are less obvious. src.class and meta.id.assoc.
• Extend UCDs to standardize the expression of enumerated values? Astronomical object types, astronomical phenomena.
• Should VOEvent be the catalyst for developing an IVOA standard vocabulary, or ontology, for astronomical objects and events? If so, at what level of granularity? Journal keywords, IAU thesaurus, SIMBAD object types…
• Alternate approach is to characterize type of light curve and use that as indicator of event type.
• Use IAU Thesaurus terms/keywords. Journal keywords? Several people at VOEvent workshop pushed for ontology approach. But folks here are concerned that this would hold up VOEvent protocol for a potentially very long time.
• Pragmatic approach might be to analyze event databases and find the most common event types, then agree on standard representations for these. Groups want to start using VOEvent protocol within the next month or two; cannot wait.

VOEvent is a trigger for creation of RTML request for observation, but does not cover both. Two functions.

Should consider promoting RTML through the IVOA standards process.

Authentication: consider adding authentication element of some sort to make sure VOEvent notifications come from trusted sources. Should use same mechanisms as other A&A approaches in IVOA.

Interfaces with other WGs:

• Registry for registering VOEvent publishers (but NOT VOEvents!)
• VOQL for SkyNode i/f’s to VOEvent databases

Joint Session with UCD Working Group

• Summary of the result of discussions on UCDs that took place during yesterday's VOEvent Session.

• Allow a 6 months period for the definition of a list of standard expressions used by the VOEvent producers.

• Discuss possible changes to the schema about the content of the <Hypothesis> schema within the VOEvent-core mailing list after this meeting.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

• BobHanisch (stand-in session chair)
• Approx. 14 people attending

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk (.ppt)
• VOEvent version 0.90 draft specification (.pdf)
• VOEvent: keeping it simple (.ppt) - AlasdairAllan
• VOEvent and UCDs (.pdf) - SebastienDerriere
• Open Issues for VOEvent (.ppt) - ArnoldRots

Notes from Meeting

VOEvent Session, Thursday 9am

Alasdair Allan

Messages

• Argues for simplicity as foremost concern
• VOEvent principal tags
  • Citations
    • Follow-up to previous event
    • Supersede previous event
    • Retract previous event
    • Combine multiple events into single thread or split single event into multiple threads
  • Curation
    • Publisher ID
    • Date
  • What
    • What was observed? Burst? Flare? Dimming?
  • Where and When
    • Location in the sky (if known) and occurrence
    • Any legal STC expression
    • Try to keep concise
  • How
    • Instrument and observing conditions
  • Hypothesis
    • Supposition about the physical nature of the event
    • Natural language
    • UCDs?
    • Replace with “Why”?
  • Description

or empty except for a Reference which can,

• Can point to other event
• Allows event to be extremely terse

Finally, each VOEvent packet has a unique ID and there are multiple VOEvent “registries” (not to be confused with resource registries)

Implementation

• Transport methods
  • Primary end-user is a computer program
• System architecture
  • Hierarchical system? Or peer-to-peer?
• VOEvent Registries
  • Central database?
  • Or packets held by publisher?
  • These are not VO Resource Registries!!
• Publishers
  • Centralized or distributed?
  • Distinguish roles of Creator and Publisher… Creator can also be Publisher of its own events, but need not be
  • Publisher must guarantee persistence/permanence of event record
• Subscription
  • Subscribers create a query and lodge it with a VOEvent database (aggregator)
  • Again, centralized vs. distributed?
  • RSS model (Really Simply Syndication) http://blogs.law.harvard.edu/tech/rss
  • Is harvesting mechanism appropriate for rapid response? Different event types have different levels of time criticality. Should there be a VOEvent-Lite for the most time critical science applications? Or split into two events, first of which is simple notice (special event type) and second of which provides further information via Citation and Reference mechanisms.

• Searching
  • Queries supported against VOEvent database. Concerns about centralization and hierarchy in which there are single points of failure.
  • Or peer-to-peer via aggregators.

How many event providers vs. how many event consumers? A few providers will provide most events. Consumers will need to filter out only those events of interest to them.

Can have rich grammar without using it all for every event.

With many publishers, how does a consumer know whom to trust? As now… consumers know providers. Does this pick up on VO security models for authentication and authorization? Anticipate need to protect against imposter event publishers, for example.

Can VOEvent standard move forward without too much concern about implementation and architecture?

Some events are based on predictions. Do these fit into this paradigm? For example, solar system events, eclipses, occultations, transits, events downstream from solar flare. Should be simple to add Prediction to Hypothesis.Classification? Or in VOEvent.Role? (test, actual, prediction).

Is there a place to express expected duration of event, or the equivalent of urgency? Add to Hypothesis? “Time to live”?

Arnold Rots

Open issues include

• Curation
  • Handling of proprietary data; authorization
  • Syntax of VOEvent Identifiers
  • Who will provide the VOEvent repositories/databases? How are event databases retained if a publisher goes out of business?
  • How long should records be retained?
• Content requirements
  • How much information is enough?
  • User needs should determine requirements. Anticipate uses beyond those of original publishers.
  • Provide sufficient information to allow coordinate transformations. Observatory location (esp. for space-based observations).
• Data issues
  • Sensitivity of observations, detection limits
  • Linked data objects
  • Classification of event types; ontology?
• Harvesting and distribution
  • Trusted contributors? Or a free-for-all?
  • Authentication? contributors, clients?
  • Broadcasting versus querying; broker services
  • Subscription parameters: keeping the volume down
  • Estimated volume (for a given subscription…how much stuff will someone want?)
• Services
  • Auxiliary services
    • Databases of known objects - moving objects, transients, etc.
    • Name resolvers
  • Query services
    • Sophistication of queries (e.g., asteroids with a > 15 au) [ancillary service]

Sebastien Derriere

VOEvent and UCDs

• UCDs provide semantic meaning of a quantity
• Provide flexibility
• Could use UCDs in VOEvent What element. Use and elements like in VOTable. For example, describe magnitude of event and observing conditions (seeing).
• Could use UCDs in Hypothesis element, though the mappings here are less obvious. src.class and meta.id.assoc.
• Extend UCDs to standardize the expression of enumerated values? Astronomical object types, astronomical phenomena.
• Should VOEvent be the catalyst for developing an IVOA standard vocabulary, or ontology, for astronomical objects and events? If so, at what level of granularity? Journal keywords, IAU thesaurus, SIMBAD object types…
• Alternate approach is to characterize type of light curve and use that as indicator of event type.
• Use IAU Thesaurus terms/keywords. Journal keywords? Several people at VOEvent workshop pushed for ontology approach. But folks here are concerned that this would hold up VOEvent protocol for a potentially very long time.
• Pragmatic approach might be to analyze event databases and find the most common event types, then agree on standard representations for these. Groups want to start using VOEvent protocol within the next month or two; cannot wait.

VOEvent is a trigger for creation of RTML request for observation, but does not cover both. Two functions.

Should consider promoting RTML through the IVOA standards process.

Authentication: consider adding authentication element of some sort to make sure VOEvent notifications come from trusted sources. Should use same mechanisms as other A&A approaches in IVOA.

Interfaces with other WGs:

• Registry for registering VOEvent publishers (but NOT VOEvents!)
• VOQL for SkyNode i/f’s to VOEvent databases

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

• BobHanisch (stand-in session chair)

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk (.ppt)
• VOEvent version 0.90 draft specification (.pdf)
• VOEvent: keeping it simple (.ppt) - AlasdairAllan
• VOEvent and UCDs (.pdf) - SebastienDerriere
• Open Issues for VOEvent (.ppt) - ArnoldRots

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

• Bob Hanisch (stand-in session chair)

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk [.ppt]
• VOEvent version 0.90 draft specification [.pdf]

• VOEvent: keeping it simple [.ppt] - (AlasdairAllan)

• VOEvent and UCDs [.pdf] - (SebastienDerriere)

• Open Issues for VOEvent [.ppt] - (ArnoldRots)

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

• Bob Hanisch (stand-in session chair)

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

• Bob Hanisch (stand-in session chair)

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk
• VOEvent version 0.90 draft specification

• VOEvent: keeping it simple - (AlasdairAllan)

• VOEvent and UCDs (.pdf)

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

• Bob Hanisch (stand-in session chair)

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk
• VOEvent version 0.90 draft specification

• VOEvent: keeping it simple - (AlasdairAllan)

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

• Bob Hanisch (stand-in session chair)

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk
• VOEvent version 0.90 draft specification

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

• Bob Hanisch (stand-in session chair)

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"
• Sebastien Derriere: "VOEvent and UCDs"
• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk
• VOEvent version 0.90 draft specification

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

• Bob Hanisch (stand-in session chair)

Timetable

Thursday, 9:00am-12:30pm

• Goals for this session
• Alasdair Allan: "All About VOEvent"
• Arnold Rots: "The Road Ahead"

• Discussion

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk
• VOEvent version 0.90 draft specification

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

Timetable

Materials and notes from the work group and plenary sessions

• The VOEvent plenary talk
• VOEvent version 0.90 draft specification

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

Timetable

Materials and notes from the work group and plenary sessions

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

InterOpMay2005 VOEvent

Participants

Timetable

Materials and notes from the work group and plenary sessions

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->