Enforcing Event to be a top level tag and other enforcement rules

[VisLab]

@dungscout96 @smakeig @sappelhoff @IanCa @happy5214 @arnodelorme

We currently have schema attributes tagGroup and topLevelTagGroup HED schema attributes so that we can enforce and validate things like Definition must be in a tag group and can't be nested.

I propose the following:

1. We add a topLevelTag HED schema attribute. We can then use this attribute with the Event tag to force it to be used at the top level.

Justification: We currently recommend this and do it in all examples, but I think should probably be enforced.

2. We add the tagGroup schema attribute to terms in the Action and Relation subtrees.

Justification: This is really for clarity in downstream processing. This will permit more consistent RDF and natural language parsing in the future.

For Relation it is clear since all these tags represent binary operations and should always be tagged as (A, (rel, B)), for example (A, (Greater-than, B)) makes clear what the order is.

For Action things are a little less clear. The issue is that (Agent, Move) could mean the agent moves or something moves the agent since tag strings are unordered. All of our examples so far have avoided the issue by having examples with direct objects such as: (Agent, (Move, Device)).

I propose that we add the tagGroup schema attribute to the Move subtree and document that (Move, A) means the action is being done to A, while (A, (Move)) or (A, (Move, B)) means that A is doing the action.

As mentioned above, we have largely avoided the issue by always using parentheses. This will help enforce, though it won't completely enforce it. Comments?

[smakeig]

Kay,

Sounds good - happy you are able to think through these things. Let's discuss later ....

On Wed, Aug 4, 2021 at 10:10 AM VisLab @.***> wrote:

@dungscout96 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dungscout96&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=VMHVZAkedgwm57SlejN6kSguWF8A5rnqXM8VUttOvBk&s=mOV-SNCzo5k06L1DJRob8F8ciDUFq_iBMZGrZXEWsx8&e= @smakeig https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smakeig&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=VMHVZAkedgwm57SlejN6kSguWF8A5rnqXM8VUttOvBk&s=qubd4ltTBFiX4K5hxDe4ZzydGMuBteQKyk9n0Mh5dXk&e= @sappelhoff https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sappelhoff&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=VMHVZAkedgwm57SlejN6kSguWF8A5rnqXM8VUttOvBk&s=599gK3dg--VyaNVnXNQPKgT4zmKMZGbXMnVSlRxxrrg&e= @IanCa https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IanCa&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=VMHVZAkedgwm57SlejN6kSguWF8A5rnqXM8VUttOvBk&s=DLdfCqIZ5YEeEeTFCDfrJdiV3QFfWj83pgUw7o9Pw1A&e= @happy5214 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_happy5214&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=VMHVZAkedgwm57SlejN6kSguWF8A5rnqXM8VUttOvBk&s=FV1nSlZ26z5_s8bUEt9x4CBJt937yuRNTZcPsnYhEwU&e= @arnodelorme https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_arnodelorme&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=VMHVZAkedgwm57SlejN6kSguWF8A5rnqXM8VUttOvBk&s=oyrv2ed4v_dK_N2l5oNmB1X6xUuKU_uBZ89JopJMpd8&e=

We currently have schema attributes tagGroup and topLevelTagGroup HED schema attributes so that we can enforce and validate things like Definition must be in a tag group and can't be nested.

I propose the following:

1. We add a topLevelTag HED schema attribute. We can then use this attribute with the Event tag to force it to be used at the top level.

Justification: We currently recommend this and do it in all examples, but I think should probably be enforced.

1. We add the tagGroup schema attribute to terms in the Action and Relation subtrees.

Justification: This is really for clarity in downstream processing. This will permit more consistent RDF and natural language parsing in the future.

For Relation it is clear since all these tags represent binary operations and should always be tagged as (A, (rel, B)), for example (A, (Greater-than, B)) makes clear what the order is.

For Action things are a little less clear. The issue is that (Agent, Move) could mean the agent moves or something moves the agent since tag strings are unordered. All of our examples so far have avoided the issue by having examples with direct objects such as: (Agent, (Move, Device)).

I propose that we add the tagGroup schema attribute to the Move subtree and document that (Move, A) means the action is being done to A, while (A, (Move)) or (A, (Move, B)) means that A is doing the action.

As mentioned above, we have largely avoided the issue by always using parentheses. This will help enforce, though it won't completely enforce it. Comments?

— 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_309&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=VMHVZAkedgwm57SlejN6kSguWF8A5rnqXM8VUttOvBk&s=zrOFkckTWmFPbrypZn5iw-k8eIe74-yHnq1Z0q_6dHE&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AKN2SFSEHM3AIS7TWKYPUL3T3FC6NANCNFSM5BRHKGAQ&d=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=VMHVZAkedgwm57SlejN6kSguWF8A5rnqXM8VUttOvBk&s=zLMru36sm_qQ3jbRWhIlGHXM7IX6-H4WLz9byXr2-RA&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=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=VMHVZAkedgwm57SlejN6kSguWF8A5rnqXM8VUttOvBk&s=Kk1_6h1tZa1YimeVKr2caZlPC4bz4CvqbeqII8eTQBQ&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=DwMFaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=VMHVZAkedgwm57SlejN6kSguWF8A5rnqXM8VUttOvBk&s=kzXULajO610BNm2msp9pFpTRwWd4XQsTIU2bLfLb7TM&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

[sappelhoff]

For the (move, a) and (a, (move)) examples, why are the extra parentheses around move needed in the second example?

[VisLab]

HED strings are unordered, so (a, b) has the same meaning as (b, a). If we want downstream tools to be able to parse Subject Verb Direct-object, we have to use parentheses. (Move, A) and (A, Move) are treated exactly the same way in HED. There is no ordering. It would be nice to have a way up front to distinguish between A moves and something else moves A.

On Wed, Aug 4, 2021 at 2:44 PM Stefan Appelhoff @.***> wrote:

For the (move, a) and (a, (move)) examples, why are the extra parentheses around move needed in the second example?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hed-standard/hed-specification/issues/309#issuecomment-892925719, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJCJOWTTH47ZCDAMHZJFV3T3GKDTANCNFSM5BRHKGAQ . 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]

We have thus far avoided discussing the issue because our examples have always explicitly had Subject Verb Direct-object which was tagged as (Subject, (Verb, Direct-object)).

On Wed, Aug 4, 2021 at 2:51 PM Kay Robbins @.***> wrote:

HED strings are unordered, so (a, b) has the same meaning as (b, a). If we want downstream tools to be able to parse Subject Verb Direct-object, we have to use parentheses. (Move, A) and (A, Move) are treated exactly the same way in HED. There is no ordering. It would be nice to have a way up front to distinguish between A moves and something else moves A.

On Wed, Aug 4, 2021 at 2:44 PM Stefan Appelhoff @.***> wrote:

For the (move, a) and (a, (move)) examples, why are the extra parentheses around move needed in the second example?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/hed-standard/hed-specification/issues/309#issuecomment-892925719, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJCJOWTTH47ZCDAMHZJFV3T3GKDTANCNFSM5BRHKGAQ . 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 .

[dungscout96]

What if "Agent" and "Object" are special tags that denote the subject and object in an action? e.g. (Move, (Agent, Experimental-subject)) vs. (Move, (Object, Experimental-subject))

We may consider removing the current Agent subtree as the type of Agent can be largely inferred. e.g. Human-agent, Animal-agent, Robotic-agent, Software-agent from its position in the Item subtree.

[VisLab]

It turns out that the specification has a case where Event must be in a top-level-tag-group and is not a top-level tag. This is where within an event, another event is expressed as a delay or offset from the current event:

Event/Sensory-event, visual-presentation, (Event/Agent-action, Delay, 1.2s, Key-press)

This ability to express things happening as offsets might be valuable in the future. Until we introduce a better way to do this, we should not limit the role of the Event tag.

[smakeig]

I would disagree with this - we should NOT encourage the lazy habit of specifying only a few relative event latencies. Instead, each event latency must be expressed on a common timeline. (Hence as well the importance for XDF data of allowing a timestamp for each data point in each LSL data stream ...)

On Thu, Aug 12, 2021 at 1:56 PM VisLab @.***> wrote:

It turns out that the specification has a case where Event must be in a top-level-tag-group and is not a top-level tag. This is where within an event, another event is expressed as a delay or offset from the current event:

Event/Sensory-event, visual-presentation, (Event/Agent-action, Delay, 1.2s, Key-press)

This ability to express things happening as offsets might be valuable in the future. Until we introduce a better way to do this, we should not limit the role of the Event tag.

— 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_309-23issuecomment-2D897849916&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=XActRNR7PMS1oLz8wI8PxgYbiDJVbXjP700JaK7xX80&s=a4B71Fde7B1Jt3LRnRRHJAogjyF5hzh5T0gjahtWxCQ&e=, or unsubscribe https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AKN2SFQLBD3NE3NVO57N7Z3T4QDOTANCNFSM5BRHKGAQ&d=DwMCaQ&c=-35OiAkTchMrZOngvJPOeA&r=KEnFjcsfiKF_BPOsgvPP9w&m=XActRNR7PMS1oLz8wI8PxgYbiDJVbXjP700JaK7xX80&s=6yhtl84TGbHbuq-MXCvF9QQ_Hv_MBS2pBqgdHAE39N0&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=XActRNR7PMS1oLz8wI8PxgYbiDJVbXjP700JaK7xX80&s=aFZOMGbN5wEsO2fs2PKOUcD7JYIxKa7xQfsueVd7oPA&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=XActRNR7PMS1oLz8wI8PxgYbiDJVbXjP700JaK7xX80&s=UVCmXAd9wMYzUaqoCR1mJ7aC-avKk2x2gg4BJ55dL8Y&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