Reorganization of Relation

[VisLab]

This thread relates to the reorganization of Relation to make clear that the items under the Relation subtree are strictly binary operations. This issue is related to issue #269, issue #280, and issue #281.

[VisLab]

Changed Left-side to Left-side-of and Right-side to Right-side-of to make clear that these are to always be tagged as (A, (Left-side-of, B)) to mean that A is on the left side of B as to designate a left-hand.

[VisLab]

Modified the Ordering-relation section to clarify that these are actually binary operations.

Example: The tag First-item is now First-item-of and the description is:

(A (First-item-of B)) means that A is the first item of B. Here B could be anything that has a linear order such as a course, process, or list.

[dungscout96]

How do we tag "pressing left button" in this case? Should we allow a dummy node in the schema?

I'm noticing there's "Left-of" and "Left-side-of" right now in 8.0.0-beta.5. Same for "Right-of" and "Right-side-of"

[VisLab]

Rename Data-type to Data-value-type to make more clear. (Data-type occurs elsewhere in OWL to mean something else.)

Move Quantitative-relation/Estimated to Data-value-type/Estimated-value

Move Quantitative-relation/Exact to Data-value-type/Exact-value

Remove Quantitative-relation/Approximated because this term is to close to Estimated

Remove Quantitative-relation as it no longer has children.

Rename Data-value-type/Categorical-type to be Data-value-type/Categorical-value as this fits better with what its children are called.

[VisLab]

As per meeting 7/29/2021 @dungscout96 @smakeig @VisLab:

Eliminate Relation/Ordering-relation

The ordering relations are being replaced by more precise ordering with streams. That is we now use:

(Event-stream/Faces, Repetition-number/1) to designate the first item in the event stream named Faces.

The expectation is that each event that is a face presentation would be annotated by (Member-of, Event-stream/Faces), This will allow automated tools to automatically identify which events correspond to faces. Events can be members of multiple streams.

[VisLab]

As per meeting 7/29/2021 @dungscout96 @smakeig @VisLab:

Eliminate the level Spatiotemporal-relation by moving Positional-relation and Temporal-relation up a level.

Also rename Positional-relation to be Spatial-relation since some members are spatial not positional (such as Boundary-of).

[smakeig]

Eliminate Relation/Ordering-relation The ordering relations are being replaced by more precise ordering with streams. That is we now use: (Event-stream/Faces, Repetition-number/1) to designate the first item in the event stream named Faces. The expectation is that each event that is a face presentation would be annotated by (Member-of, Event-stream/Faces), This will allow automated tools to automatically identify which events correspond to faces. Events can be members of multiple streams.

Good - then is there a place to define the 'Faces' stream with a Description ? However, the term 'Repetition-number' doesn't imply index in the stream series ... better to use 'Stream-index' (when needed). ? In the H&W case where repetition (of a single face image) is important, should we want to declare each new image a new stream?? For one, inventing labels for them all would be bothersome and likely the results confusing ... Better to use a tag 'Repetition-of' taking an event number --- But are there event numbers?? So, I'd suggest 'Repeat-presentation', # where # = 0 meaning this is not a repeat of a previous presentation, # = 1 means 1st repetition, etc...

[smakeig]

How do we tag "pressing left button" in this case? Should we allow a dummy node in the schema?

Dummy mode = ?

I'm noticing there's "Left-of" and "Left-side-of" right now in 8.0.0-beta.5. Same for "Right-of" and "Right-side-of"

Were the intended meanings "To-left-of" and "Left-side-of" respectively?

I'm wondering if each Item introduced should not receive an index number. ... ?

[smakeig]

Modified the Ordering-relation section to clarify that these are actually binary operations.

Example: The tag First-item is now First-item-of and the description is:

(A (First-item-of B)) means that A is the first item of B. Here B could be anything that has a linear order such as a course, process, or list.

Can you give a use example??

[smakeig]

Changed Left-side to Left-side-of and Right-side to Right-side-of to make clear that these are to always be tagged as (A, (Left-side-of, B)) to mean that A is on the left side of B as to designate a left-hand.

Yes, but how is B described ... as an already-identified item or agent? If so, having some index number scheme for items and for agents should be a good idea... For example, (A, (Left-side-of, Tree)) ... Does this mean the tree in the picture that was already tagged, or some other (new) tree?? ...

[VisLab]

Yes Left-of should be To-left-of. I'll make the change.

The index number and the Repeat seem reasonable, but I have questions on the details. Let's discuss this at Monday's meeting.

On Fri, Jul 30, 2021 at 12:12 PM smakeig @.***> wrote:

How do we tag "pressing left button" in this case? Should we allow a dummy node in the schema?

Dummy mode = ?

I'm noticing there's "Left-of" and "Left-side-of" right now in 8.0.0-beta.5. Same for "Right-of" and "Right-side-of"

Were the intended meanings "To-left-of" and "Left-side-of" respectively?

I'm wondering if each Item introduced should not receive an index number. ... ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hed-standard/hed-specification/issues/284#issuecomment-890035146, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJCJOSVHGQ5Z7PPZXABCN3T2LMQBANCNFSM5BGMG3NA .

[dungscout96]

Thinking about a more general solution for the event stream specification problem (syntax and naming used below is only for demonstration purposes. They might not be precise and are not final syntax proposal):

• When specifying event stream, user can associate it with a definition. e.g. (Event-stream/Face-presentation, Def/Show-face)
• When assembling HED annotations, HED tools can automatically put in "Event-stream-index/#" to each event in the stream containing the definition, automatically incrementing index number. Onset/Offset mechanism can be used to indicate start and stop of the stream, as well as reset. If need to, we can consider automatically numbering different instantiations of the same event stream type.
• So the 12th show-face event will include "(Event-stream/Face-presentation, Event-stream-index/12)" in its HED string. An event can belong to multiple streams, which means that it can have multiple "(Event-stream/#, Event-stream-index/#)" tag groups. This provides enough evidence for derived annotation, which to be explained next:
• We can write functions that sub-select events within a stream based on HED tags. For example, getIdenticalEvents(event_stream, HED_tag) --> getIdenticalEvents(Face-presentation, Image-path) can pull out all sets of events that belong to the Face-presentation stream that has identical image file paths. Image-path/# is part of the HED string for each event and uniquely identifies the face images. This opens up the possibility of annotating other kinds of combination for events within a stream, using other HED tags.
• The result of function above can then be used as indices to pass to the next set of functions, which add HED tags to the selected events using specific criteria. For example, autoincrement(event_indices, HED_prefix) --> autoincrement(identical_face_presentation_events, Repetition-number/#) will add repetition number automatically in incrementing order for the events in the set. Or pariwiseStreamIndexDistance(event_indices, HED_prefix) --> pairwiseStreamIndexDistance(identical_face_presentation_events, Occurrence-interval/#) will add interval between each pair of the events in the set using Event-stream-index/# in their HED strings.
• All these functions called should be documented, either in a designated file (e.g. hed_derived_annotation.m) or automatically (similarly to eeglab history mechanism). In this manner, we have full governance and integrity check for derived annotations.

This line of thinking suggests that annotations entailing relationships between events should be done via documented HED-enabled functions/APIs, instead of direct tagging. Direct annotation should only be done for stand-alone, unambiguous aspects of events (e.g. description of what was presented on the screen). This takes away the burden of handling complex logic from the HED syntax, while allowing governance of how derived annotations were made.

Just some rough ideas...

[smakeig]

Good thinking, Dung -

Yes, Event-stream labels are useful for incorporating the exp design logic in the annotation. They are useful in building analysis scripts - but may rarely be needed to document the experiment Event details....

On Mon, Aug 2, 2021 at 2:31 PM Dung Truong @.***> wrote:

Thinking about a more general solution for the event stream specification problem (syntax and naming used below is only for demonstration purposes. They might not be precise and are not final syntax proposal):

• When specifying event stream, user can associate it with a definition. e.g. (Event-stream/Face-presentation, Def/Show-face)
• When assembling HED annotations, HED tools can automatically put in "Event-stream-index/#" to each event in the stream containing the definition, automatically incrementing index number. Onset/Offset mechanism can be used to indicate start and stop of the stream, as well as reset. If need to, we can consider automatically numbering different instantiations of the same event stream type.
• So the 12th show-face event will include "(Event-stream/Face-presentation, Event-stream-index/12)" in its HED string. An event can belong to multiple streams, which means that it can have multiple "(Event-stream/#, Event-stream-index/#)" tag groups. This provides enough evidence for derived annotation, which to be explained next:
• We can write functions that sub-select events within a stream based on HED tags. For example, getIdenticalEvents(event_stream, HED_tag) --> getIdenticalEvents(Face-presentation, Image-path) can pull out all sets of events that belong to the Face-presentation stream that has identical image file paths. Image-path/# is part of the HED string for each event and uniquely identifies the face images. This opens up the possibility of annotating other kinds of combination for events within a stream, using other HED tags.
• The result of function above can then be used as indices to pass to the next set of functions, which add HED tags to the selected events using specific criteria. For example, autoincrement(event_indices, HED_prefix) --> autoincrement(identical_face_presentation_events, Repetition-number/#) will add repetition number automatically in incrementing order for the events in the set. Or pariwiseStreamIndexDistance(event_indices, HED_prefix) --> pairwiseStreamIndexDistance(identical_face_presentation_events, Occurrence-interval/#) will add interval between each pair of the events in the set using Event-stream-index/# in their HED strings.
• All these functions called should be documented, either in a designated file (e.g. hed_derived_annotation.m) or automatically (similarly to eeglab history mechanism). In this manner, we have full governance and integrity check for derived annotations.

This line of thinking suggests that annotations entailing relationships between events should be done via documented HED-enabled functions, instead of direct tagging. Direct annotation should only be done for stand-alone, unambiguous aspects of events (e.g. description of what was presented on the screen). This takes away the burden of handling complex logic from the HED syntax, while allowing governance of how derived annotations were made.

Just some rough ideas...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hed-2Dstandard_hed-2Dspecification_issues_284-23issuecomment-2D891242282&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=bOIpiJp-1rNrZQ6bxNBB-ARMad3eXCOgwoZ5sgfxScY&s=Q6VwIvvIaQjVQl825JdZjGdOAgpgrYjKKT5f7HuH8Ck&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AKN2SFT7NVAGM2B4LX65RBDT23QBXANCNFSM5BGMG3NA&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=bOIpiJp-1rNrZQ6bxNBB-ARMad3eXCOgwoZ5sgfxScY&s=e6ZuKY4DFedbxUmXUIWTl_P6oWRns7YapN91u8IVgM4&e= . Triage notifications on the go with GitHub Mobile for iOS https://urldefense.proofpoint.com/v2/url?u=https-3A__apps.apple.com_app_apple-2Dstore_id1477376905-3Fct-3Dnotification-2Demail-26mt-3D8-26pt-3D524675&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=bOIpiJp-1rNrZQ6bxNBB-ARMad3eXCOgwoZ5sgfxScY&s=N3O8xvsf6cSWvwZzIBxObf5qF6Vp7158jYdMQKMBWG8&e= or Android https://urldefense.proofpoint.com/v2/url?u=https-3A__play.google.com_store_apps_details-3Fid-3Dcom.github.android-26utm-5Fcampaign-3Dnotification-2Demail&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=bOIpiJp-1rNrZQ6bxNBB-ARMad3eXCOgwoZ5sgfxScY&s=1Fb1za6oJdsOkwvID4TH16fb4h00buY0uTni7tQNKhI&e= .

-- Scott Makeig, Research Scientist and Director, Swartz Center for Computational Neuroscience, Institute for Neural Computation, University of California San Diego, La Jolla CA 92093-0559, http://sccn.ucsd.edu/~scott

[VisLab]

This was debated extensively at meeting of 8/2/2021 (@smakeig @dungscout96 @VisLab). It was decided to not do major additions of Event-stream support although the concept of Event-stream will be supported. The concept of Parameter was reintroduced to be used to annotate experiment-specific concepts like repetition.

Property

• Informational-property
  • Parameter
  • Parameter-label
  • Parameter-value

[VisLab]

@makeig @dungscout96

I have been working through the write-up in the specification and it solves some problems but not all of our problems. I think we should encourage people to use Parameter rather than extending tags for things that are specific to experiments. I still need think we need to be able to express the interval between something and the count of something in the HED hierarchy.

Example: Use Parameter to express the fact that this is the second time that this particular face has appeared and that it last appeared 15 faces ago:

(Parameter-label/Count-of-this-face, Parameter-value/2) (Parameter-label/Face-count-since-this-face-appeared-last, Parameter-value/15)

This is all well and good. However, Parameter-value provides no information about the kind of value and cannot have units. We have Temporal-value/Time-value and Temporal-value/Time-interval for time measures that have time units and are numeric. I think we should have two corresponding things for counts: Quantitative-value/Count and Quantitative-value/Count-interval . Thus, I think the following is preferred so that tools know the values are numeric and integers.

(Parameter-label/Count-of-this-face, Count/2) (Parameter-label/Face-count-since-this-face-appeared-last, Count-interval/15)

We might also put additional information in:

(Parameter-label/Count-of-this-face, Count/2, (Face, Image)) (Parameter-label/Face-count-since-this-face-appeared-last, Count-interval/15, (Face, Image))

[smakeig]

Kay/Dung -

I was thinking while waking up this morning that a large 'missing piece' in current HED-3G is the task design ... and the most essential elements of it are not difficult to begin on - namely, the issue of imperative stimuli:

For the oddball:

button_press_stream, '(...)' stream tone_stream stream standard_stream '(...)' stream target_stream, '(..., (imperative, button_press_stream)' and define target, '(..., target_stream)' define standard, '(..., standard_stream)'

This sets up the imperative, target --> button_press

A second thought

trial specification: Again, for ease of analysis

trial standard_trial, '(fixation_cross, (delay, 500)', tone_stream, button_press_stream, (delay, delay_min, 500, delay_max, 900))'

My thought is that syntax for the above 4 concepts (stream, imperative, trial, delay) will allow tagging alot of tasks...

??

Scott

[VisLab]

Yes, I think this is promising..... we should work through some examples.

On Sun, Aug 8, 2021 at 3:32 PM smakeig @.***> wrote:

Kay/Dung -

I was thinking while waking up this morning that a large 'missing piece' in current HED-3G is the task design ... and the most essential elements of it are not difficult to begin on - namely, the issue of imperative stimuli:

For the oddball:

button_press_stream, '(...)' stream tone_stream stream standard_stream '(...)' stream target_stream, '(..., (imperative, button_press_stream)' and define target, '(..., target_stream)' define standard, '(..., standard_stream)'

This sets up the imperative, target --> button_press

A second thought

trial specification: Again, for ease of analysis

trial standard_trial, '(fixation_cross, (delay, 500)', tone_stream, button_press_stream, (delay, delay_min, 500, delay_max, 900))'

My thought is that syntax for the above 4 concepts (stream, imperative, trial, delay) will allow tagging alot of tasks...

??

Scott

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hed-standard/hed-specification/issues/284#issuecomment-894851533, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJCJOQSS4LSNGWOVFN5HCLT33SU3ANCNFSM5BGMG3NA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[VisLab]

Reorganization has been completed with the release of HED8.0.0.