hansenlaw with gradient calculated as a first-order finite difference

For hansenlaw evaluate the image row gradient as a first-order finite difference, as per @MikhailRyazanov suggestion:

Well, in one dimension, “gradient” is the derivative. But I see that PyAbel actually calculates it using numpy.gradient, which assumes “that f ... has at least 3 continuous derivatives” — I think, this is way too much to expect from any experimental data.

Basically, the problem is that NumPy uses the two-sided formula to estimate the derivative at the grid points, whereas our integral (2) actually needs the derivatives within the integration intervals. I suspect that using the standard first-order finite differences and choosing the integration points half-way between the image sample points will work better. For the “direct” method at least, I don't know how the Hansel–Law method works.

Bonus, the sub_pixel_shift=-0.35 grid-alignment (for hold_order=0) is no longer required, and has been dropped.

This looks cool! I'm still catching up on your other discussion with @MikhailRyazanov, but can you post a before/after comparison figure here and/or elaborate a bit on how this helps?

The hansenlaw inverse Abel transform operates on the gradient image, and this was implemented using drive = numpy.gradient(image, dr, axis=-1). My interpretation of @MikhailRyazanov numpy.gradient comment is that the derivative calculation requires more than just adjacent points, and so fails if there is any sharp structure. I agree with his comment:

using the standard first-order finite differences ... will work better

This has been implemented by replacing np.gradient() with a sliced difference: drive[:, :-1] = (image[:, 1:] - image[:, :-1])/dr
Test case: We have been investigating the inverse Abel transform of a comb of 1-pixel-width peaks (with noise). Here are the before and after images, comparing the hansenlaw inverse Abel transform with the noiseless source function (blue). Note the improved agreement with the first-order difference method (after):

This change also resolves a long standing issue concerning image alignment of the hansenlaw inverse Abel image, that required a post transform image shift of -0.35 pixels, which is now, no longer required. It seems the numpy.gradient() does some funny business related to

two-sided formula to estimate the derivative at the grid points

vs

needs the derivatives within the integration intervals

numpy.gradient ... the derivative calculation requires more than just adjacent points, and so fails if there is any sharp structure.

Yes, as I understand from its documentation, it does
grad[i] = (f[i+1] - f[i-1]) / (2 * dr)

instead of
grad[i] = (f[i+1] - f[i]) / dr

or
grad[i] = (f[i] - f[i-1]) / dr

So basically returns the derivative averaged over the two adjacent intervals and needs 3 points (actually does not use the central one, but needs this 3-point span).
You can also try whether numpy.ediff1d or numpy.diff will work faster than Python slices.

interesting to look at the Gaussian results “before” and “after”

Here are the transform pairs code gist, before (gradient) and after (1st-order-difference):
1st-order difference produces a slight improvement, except with hold_order=1, which prefers np.gradient().

gradient

gradient
profile  hansenlaw   basex    3pt
1        3.92e-06  5.21e-08  3.08e-08
2        3.01e-06  6.50e-08  5.82e-09
3        3.22e-06  7.00e-08  5.68e-09
5        5.02e-04  1.00e-02  4.93e-03
6        5.25e-06  6.03e-08  6.76e-08
7        5.44e-06  7.79e-08  4.35e-08

1st-order-difference

1st-order-diff
profile  hansenlaw   basex    3pt
1        1.31e-06  5.21e-08  3.08e-08
2        1.16e-06  6.50e-08  5.82e-09
3        1.14e-06  7.00e-08  5.68e-09
5        1.32e-03  1.00e-02  4.93e-03
6        3.06e-06  6.03e-08  6.76e-08
7        3.42e-06  7.79e-08  4.35e-08

@MikhailRyazanov note there is something odd with basex for profile5
For the Gaussian function, the agreement slightly degrades, from 0.23% to 0.33%:

Given the large improvement for the comb structure, and the excution time improvement(*) from dropping interpolation.shift,  I am in favour of merging this PR (after the onion_bordas.py PR)
(*) gradient
In [6]: %timeit abel.Transform(imc, method='hansenlaw')
275 ms ± 10.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
1st-order-difference
In [6]: %timeit abel.Transform(imc, method='hansenlaw')
157 ms ± 841 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)

So I would say that hansenlaw now produces results almost identical to two_point, except r = 0 (I have noticed this in your comb figure). Which is interesting, since if this holds for large images as well, then hansenlaw will be the fastest (and among the highest-resolution) method for them. Especially after becoming more computationally efficient. I'm not sure that it can actually beat two_point and reach the “HD video” goal, but it should get very close.
(I'll take a look at what happens with basex.)

This seems to work well. Should we go ahead and merge?


Add support for opening from Xiaomi camera app

I know this is unlikely to be implemented, but it's still worth a try. Some time ago I sadly bought a Xiaomi phone. I have disabled builtin gallery app, as it was buggy and privacy nightmare. However, I did not find a good replacement for the camera app, so I use the stock one. Naturally, it has an option to open last taken photo, but it does not work with anything else than stock gallery app. No app even opens when I select it, only Termux. I post all details. If would you manage to find time, I will do anything on my device to help you.
Describe the solution you'd like
Be able to open this gallery app from stock Xiaomi camera.
Describe alternatives you've considered
Switching to another camera app, but I didn't find any what would work as well as stock one.
Additional context

On your second screenshot i see a selection of galley apps, including Aves. When you select it, it opens Aves but you don't see the photo? If that's the case, try it and then, in the app go to About> Bug Report, save the logs and then attach them here.

It does not open at all, stays in the camera app, just the camera app behaves like it was reopened (blurry loading image and then it loads data from camera sensor). I will try to get logs now.

Nothing got logged at all, event time is exactly 9:09
aves-logs-20230825_091013.txt

Could you install this app https://github.com/MuntashirAkon/AppManager and see if you can select that app when you select an app to open the photo? If it works you should get details about the intent, please screenshot that.

Unfortunately it does not, I will try to fill a issue with them, if they manage to do anything.

I see. Then i don't think i can do anything on my side.

The developer of that application is very quick and implemented it. Here is the screenshot:

The text, so you don't have to rewrite it:
content://media/external/images/media/1000001970
intent://media/external/images/media/1000001970#Intent;scheme=content;launchFlags=0x3000000;end

Thanks!
For reference:

https://github.com/MuntashirAkon/AppManager/issues/1155
fixed by https://github.com/MuntashirAkon/AppManager/commit/2e84e0407ef2dcf39814c61cc343690d13a82048

I noticed that the URI changed, when I did a picture and opened it while the device was locked, attaching for reference:

Id is different probably because it is different photo, but the "_primary" is only present if opening when the device is locked.

Thanks for the precision. I'm aware of that kind of variation in the media url, but here i believe it's related to different intents and/or mime types. I'll inspect the fix from AppManager and come back to you with a test build soon™.

Thank you for the effort. While I was poking around and installing a lot of stuff from F-Droid, I found that Material Files application can handle this, it opens the picture, although I would rather prefer if I can swipe to older ones, not to be stuck on the latest one. Maybe you could also inspire there.

Here's a test build:
https://drive.google.com/file/d/11vALMyGuS3SgTNsEZnnLNfqeUUE3TTHX/view?usp=sharing
It will install as "Aves [Profile]", so try to select that app (not the regular "Aves") to open your camera image, and please let me know whether it works.
But something does not add up from your original report. You say that you see Aves in the list of apps you can choose from, and that's consistent with the fact that the intent is android.intent.action.VIEW (Aves can handle these intents). But from the logs, I only see Aves started with the generic android.intent.action.MAIN, I see no call with android.intent.action.VIEW, as if Aves had never been selected.
So if you still can't open the image with Aves, please attach your system info and logs from About > Bug Report as well as a screen recording. And if you know what logcat is, please attach full logs from logcat at the time you tried to open the image with Aves.

Does not work, I will try the logcat later today.

Also: "please attach your system info and logs from About > Bug Report as well as a screen recording".

aves-logs-20230903_134700.txt
Time was around 13:35.
https://youtu.be/_AX8nS3OJlo?si=0KA6MjSc59e0TTQe
I will find out how do do the logcat now. Also found Amaze tools can open the image too.

In the AppManager screenshots you attached here and here, I don't see whether there were "Extras" (it's the section below "Flags"/"Vlajky"). Could you please screenshot that section?
Also, if you catch the intent via AppManager first, then you can see matching activities at the bottom. You should see Aves main activity, among others. If you forward the intent to it from there, do you get the same behaviour (i.e. Aves does not even open)?

There is nothing in extras.
When I use interceptor and then launch the activity from it to Aves, it works in both stable and the one you sent.

When I use interceptor and then launch the activity from it to Aves, it works in both stable and the one you sent.

Unless the interceptor modifies the intent, this means Aves can deal with the intent from Xiaomi. Without checking what's going on in logcat, I'm afraid there's nothing more I can do here.

Sorry for not doing the logcat yet, it's on my todo list, but the phone is now broken and I use a backup one. If the phone gets repaired, I will send it here and you will see if you can do anything about it.

I have sent you an email, the attachment was big, so I am not sure if it did arrive. Just for inspiration, Interceptor did not open before the same as Aves does not, this is how the author fixed it: https://github.com/MuntashirAkon/AppManager/commit/2e84e0407ef2dcf39814c61cc343690d13a82048 . Maybe it could help if the logcat won't.

Here's a test build:
https://drive.google.com/file/d/1AMxo_4tcNw0bZRXL2k0WlASmvGaLAcrT/view?usp=sharing
It will install as "Aves [Profile]", so try to select that app (not the regular "Aves") to open your camera image, and please let me know whether it works.

Here's a test build:
aves-play-profile_727_20230101_2115.apk
It will install as "Aves [Profile]", so try to select that app (not the regular "Aves") to open your camera image, and please let me know whether it works.

Thank you very much for your effort. I will test as soon as I get the working phone back.

I am very sorry, but the 2nd repair shop has my from 22.11. and still no response, I hope you don't take this personally, I am very grateful for all of your work.

No worries, it's for you. I just prefer to close this as I can't work on it any further without additional insight.


xcb-util-wm: Build a bottle for Linuxbrew

From https://travis-ci.org/Linuxbrew/homebrew-xorg/builds/159687181#L1896-L1898
Error: 1 problem in 1 formula
linuxbrew/xorg/xcb-util-wm:
  * Stable: Please use https:// for http://xcb.freedesktop.org/dist/xcb-util-wm-0.4.1.tar.bz2

I'll fix this in a separate PR.


Remove index routes as a separate concept

We don't really need this any more. Given that we already support something like:
<Route path="foo" component={A}>
  <Route component={B}>
    <Route component={C}>
      <IndexRoute component={D} />
    </Route>
  </Route>
</Route>

We may as well just get rid of index routes as a concept and just use pathless leaf routes, e.g.:
<Route path="foo" component={A}>
  <Route component={B}>
    <Route component={C}>
      <Route component={D} />
    </Route>
  </Route>
</Route>

<Route path="foo" component={A}>
  <Route component={B}/>
  <Route component={C}/>
</Route>

Who wins? You're going to say B.
<Route path="foo" component={A}>
  <Route component={B}/>
  <Route component={C}>
      <Route component={D}/>
  </Route>
</Route>

Who wins? Still B. But now our matching function has to traverse the entire route config until it realizes its done and never found a leave node, so it goes back and picks B.
It's also super unclear.
IndexRoute is a the hint to both the developer looking at your route config and the matching function to stop.

I'd actually consider B the leaf node above there, and stop as soon as we get to B, but I agree that this is potentially less clear.

<Route path="foo" component={A}>
  <Route component={B}/>
  <Route component={C}>
      <Route path="bar" component={D}/>
  </Route>
</Route>

How would you know to stop at B w/o traversing down to D?

You'd stop at the first branch where no routes have paths, when you get to a route with no children. Once the matching get to B, it'd see that B satisfies the "path-less branch with no children" condition, and terminate the match there.
We have most of this logic already in https://github.com/reactjs/react-router/blob/master/modules/matchRoutes.js#L30-L57, to handle the case where the <IndexRoute> is nested under (potentially many) path-less <Route>s.

ah gotcha, well, still seems harder to talk about than IndexRoute. IndexRoute is basically the name for this entire conversation.

That snippet from matchRoutes is where this idea comes from, BTW.
Before we added the "index route under pathless route" feature, we could just terminate matching on an exact match, and go directly to the index route.
With the new logic, we might end up iterating through child routes regardless. In other words, we can essentially replace all instances of index routes with just pathless routes, and still have everything just work, without any real increase in code complexity.
So purely from an engineering perspective, the concept of explicit index routes doesn't get us anything, but I am now leaning toward thinking that it's clearer to see an <IndexRoute> configuration component or indexRoute key as appropriate.


Excel formulae for checking the computations

It would be nice to have a node which creates the same results as cellHTS2
-at least for the less complex ones- to be easier to interpret the results,
and to be able to modify if necessary.

Original issue reported on code.google.com by aborgabor on 3 Dec 2008 at 1:08

Closing as wontfix, because CellHTS2 is no longer supported.


[BUG] Some taint tolerations can not be set, but Longhorn should run on all nodes

Describe the bug
It is not possible to set all possible taint tolerations. Note that tools like RKE set taints, e.g. node-role.kubernetes.io/etcd=true:NoExecute or node-role.kubernetes.io/controlplane=true:NoSchedule.
The description in the Longhorn UI says

Because kubernetes.io is used as the key of all Kubernetes default tolerations, it should not be used in the toleration settings.

This suggests that such tolerations can be set - but in fact, it is not allowed at all. And my understanding from other bug reports is that Longhorn should be deployed on all nodes (see e.g. https://github.com/longhorn/longhorn/issues/1633#issuecomment-702967887) because a pod using a Longhorn volume could be deployed anywhere (and have special tolerations). Imho this is contradictory.
To Reproduce
Steps to reproduce the behavior:

Go to the Longhorn UI
Set a toleration like node-role.kubernetes.io/controlplane=true:NoSchedule, try to save changes
Validation fails with

fail to set settings with invalid taint-toleration: value node-role.kubernetes.io/controlplane=true:NoSchedule of settings taint-toleration is invalid: the value of taint-toleration is invalid: the key of Longhorn toleration setting cannot contain "kubernetes.io" since this substring is considered as the key of Kubernetes default tolerations

Expected behavior

allow taint toleration for all taints that can exist
also allow wildcard tolerations - see https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#concepts ("There are two special cases" box)
(potentially) improve description in Longhorn UI

Log
Environment:

Longhorn version: 1.0.2
Kubernetes version: 1.18.9
Node OS type and version: Ubuntu 18.04

Additional context
See https://github.com/longhorn/longhorn-manager/blob/55c8453c22b0f47da54bb6922e0ac97c37154b75/upgrade/v1alpha1/types/setting.go#L439 (validation rule and code for parsing)

cc @shuo-wu

OK. It seems that all tolerations should be allowed in Longhorn. But we need to be careful of removing the tolerations.

In fact, the workload shouldn't be deployed when node-role.kubernetes.io/controlplane=true:NoSchedule is set. Only the worker nodes which can run workload needs to install Longhorn. We don't need to install Longhorn on control/etcd nodes. So we don't expect the user to set those taint tolerations.

Just because it is not normal to run a workload there, does not mean that there is no use-case for it ;-)
So I'm for giving the user the possibility to do it. A warning in the tolerations description is sufficient imho.
(Context why I even looked at this, a bit off-topic: I had the problem twice that even a local volume bind (!) with a local-storage storage class did not work on a node with a taint. In the kubelet logs of this node I found an error that no connection to longhorn was possible. That's why I wanted to add this node to Longhorn. But this is fairly recent, I did not see this problem before.  Maybe it is connected to an k8s upgrade (1.18.9). I need to observe and investigate and create an extra bug for this if necessary.)

I remember we set the limitation due to we have some potential issues with removing taint like kubernetes.io but I cannot recall the detail now. @shuo-wu might remember more about the topic.

My use-case: in a kubeadm bootstrapped dev cluster, I want to use control plane nodes as storage nodes, too.
Current workaround: add node-role.kubernetes.io/master=:NoSchedule to longhorn-manager DaemonSet and, after things are started, add the same toleration to the engine-image-ei-abcd1234 DaemonSet, which I guess is created by longhorn-manager.

Ping @shuo-wu . What's the reason we didn't allow taint with suffix like kubernetes.io?

@yasker
In the current implementation, there is no way to identify which tolerations of Longhorn workloads are added by Longhorn. Then we just consider all tolerations are set the Longhorn. But Kubernetes will add some tolerations (containing kubernetes.io ) by default, hence these kind of tolerations are considered as exceptions.

OK, it seems we can partly solve this problem by adding one more annotation regarding which toleration is added by Longhorn. Though if both Longhorn and Kubernetes add the same toleration, then we might still accidentally remove it. I guess that would be fine for now.

Sounds good. And I would even call that intended behavior that it is possible to override/change a default toleration.

Test Steps:

Go to the Longhorn UI
Set a toleration like node-role.kubernetes.io/controlplane=true:NoSchedule, try to save changes
Verify that Longhorn applies the toleration to components.
Manually add test.kubernetes.io/test=true:NoSchedule to any deployment/daemonset in Longhorn system.
Go to the Longhorn UI
Set a toleration like key1:val1=true:NoSchedule, try to save changes
Verify that Longhorn applies key1:val1=true:NoSchedule and removes node-role.kubernetes.io/controlplane=true:NoSchedule toleration to/from components.
Verify that Longhorn does not remove test.kubernetes.io/test=true:NoSchedule toleration
Try adding invalid toleration  key1=val1:Effect in Longhorn UI
Verify that cannot update the setting
Try adding special toleration  : in Longhorn UI
Verify that daemonsets in the Longhorn system are deployed on every node (including controller/etcd nodes)

Verified with longhorn-master 11/26/2020
Validation - Passed
Validated the test cases from https://github.com/longhorn/longhorn/issues/1874#issuecomment-729242290 and additional test cases for deletion of toleration with same key and different value.

@PhanLe1010 @yasker While upgrading the longhorn (having toleration) from v1.0.2 to master, the below intermittent issue is observed.
The longhorn manager pods initially fail with error crashloop and then recover after sometime. Is it something that we can overlook?
time="2020-11-28T07:39:24Z" level=info msg="Start overwriting built-in settings with customized values"
W1128 07:39:24.948114       1 client_config.go:541] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
time="2020-11-28T07:39:24Z" level=info msg="cannot list the content of the src directory /var/lib/rancher/longhorn/engine-binaries for the copy, will do nothing: Failed to execute: nsenter [--mount=/host/proc/19196/ns/mnt --net=/host/proc/19196/ns/net bash -c ls /var/lib/rancher/longhorn/engine-binaries/*], output , stderr, ls: cannot access '/var/lib/rancher/longhorn/engine-binaries/*': No such file or directory\n, error exit status 2"
I1128 07:39:24.964600       1 leaderelection.go:241] attempting to acquire leader lease  longhorn-system/longhorn-manager-upgrade-lock...
I1128 07:39:24.992407       1 leaderelection.go:251] successfully acquired lease longhorn-system/longhorn-manager-upgrade-lock
time="2020-11-28T07:39:24Z" level=info msg="Start upgrading"
time="2020-11-28T07:39:25Z" level=info msg="No API version upgrade is needed"
time="2020-11-28T07:39:25Z" level=error msg="Upgrade failed: upgrade Pods failed: upgrade from v1.0.2 to v1.1.0: upgrade instance manager pods failed: failed to update toleration annotation for instance manager pod instance-manager-r-f0a4823d: Operation cannot be fulfilled on pods \"instance-manager-r-f0a4823d\": the object has been modified; please apply your changes to the latest version and try again"
time="2020-11-28T07:39:25Z" level=info msg="Upgrade leader lost: khush-test-lh-wk2"
time="2020-11-28T07:39:25Z" level=fatal msg="Error starting manager: upgrade Pods failed: upgrade from v1.0.2 to v1.1.0: upgrade instance manager pods failed: failed to update toleration annotation for instance manager pod instance-manager-r-f0a4823d: Operation cannot be fulfilled on pods \"instance-manager-r-f0a4823d\": the object has been modified; please apply your changes to the latest version and try again"

@PhanLe1010 Not sure why the upgrade process can fail due to conflict (since there should be only one manager at the time of upgrade). Can you look into it?


Several style Size & Color improvements

Improvements & little fixes after the Design Review

[x] text ellipsis on 'by-value' option
[x] fix small line height on 'by-value' column name
[x] colorbar with no gradient, but solid colors
[x] fix stroke color label
[x] auto-open select-by-column dialog in size/point by-value styles
[x] hide numeric fields from fill-color by-value in animations (see: https://github.com/CartoDB/cartodb/issues/13975)

retest this please


shadow scene node crashing

Crash_2022_7_4_16-21-49.txt
This was supposedly fixed by engine fixes a while ago but ever since installing PR2 I've been getting these in random places again. One was windhelm marketplace, another in the LotD museum in the relic preparation room and now in the college hall of attainment.
It's always the same type of crash, names a mesh inside  nif and then shadow scene node. I'll try playing for a while without improved camera to get some more conclusive data.

Looks like an issue with:
Nordic Ruins of Skyrim.esp
However speaking from limited experience Lux can also cause this if the loadorder for it is out of whack, as when I started testing with a modded game around Riverwood which was working fine then did a new game with LAL I kept instantly CTD when moving. Initially yes it was experimental hooks from Improved Camera (which none of the PR's have at all). Still happened after not having it running then figured out Lux was the last thing I installed and didn't have the loadorder of it setup correctly.
There is even no mention of Improved Camera throughtout other than it is loaded.

I doubt it's the nordic ruins, as I said this also happened inside Windhelm and inside the LotD museum even. Nordic ruins also only uses vanilla assets.
Windhelm even had a vanilla mesh as the possible releva
Crash_2022_7_4_12-41-7.txt
nt objects so I don't think it's Lux meshes crashing either.

Either way nothing points to improve camera it is not even in the stack trace for either log report. Looks like you have possibly multiple issues with your mods.
From both of your reports:

BSTriShape(Name: WinterholdSBTowerIntStairs01:1.001)
BSMultiIndexTriShape(Name: WHdockdoortrim:68)

as I said, the second mesh is vanilla, there's nothing touching that at all. First one is a Lux mesh

Closing this as getting nowhere.


General internationalization available

I tried to run the application with German locale DE.de and it worked fine, at least it did not give me any run-time error. How about the locale NO_COUNTRY.no_language? Can it really handle this? I'm not really sure because of its general silent behavior. Could you confirm general support for all locales, please?

This package supports the following locales:


0.5.6 version pulling in extra files

When running typedoc with a single file, the 0.5.6 version is now pulling in all .d.ts files in the project. This was not the behavior in 0.5.5 and might be due to the recent change around the --exclude switch https://github.com/TypeStrong/typedoc/commit/6ddb7f59766aa0929a94f170dd9165921925036b.

Yes, there was a bug in #387 which makes the exclude option required. As was noted on 6ddb7f5, you can workaround this by adding a dummy --exclude xx. Thanks for submitting an issue for this. PRs are welcome.

When you say 0.5.6 is pulling in all the .d.ts files, do you mean that docs are being generated for .d.ts files?

Yes, our .json file which included generated types for one TypeScript .d.ts file went from 713K to 13M when all the node_modules TypeScript .d.ts files where pulled in. No change in the project, just an upgrade from TypeDoc 0.5.5 to 0.5.6.

Hmmm...at a guess I'd say the issue is probably due to the addition of directoryExists to TypeDoc's CompilerHost class. This allows the TypeScript compiler's automatic type discovery to work, which will find types in node_modules/@types by default. If you're using --includeDeclarations, that could cause all the discovered types to be documented.
Try using a combination of --externalPattern and --excludeExternals to prevent docs being generated for those files while still allowing them to be used by the TS compiler during the generation process. I've been doing something like --externalPattern '**/+(node_modules|tests|typings)/**/*.ts' --excludeExternals.


fix: handle missing runWithPriority with preact

close #35

@mischnic
Assuming you are familiar with yarn resolutions, would you be able to try the build by codesandbox in this PR?

@mischnic
Assuming you are familiar with yarn resolutions, would you be able to try the build by codesandbox in this PR?

Setting a new state doesn't seem to work: https://github.com/mischnic/jotai-preact-demo
The text in the input field cannot be changed.

Setting a new state doesn't seem to work: https://github.com/mischnic/jotai-preact-demo
The text in the input field cannot be changed.

Hmm, we need to investigate more to understand the problem.
Would you help? Could you try use-context-selector only example to see if the issue is this or jotai?

Hmm, we need to investigate more to understand the problem.
Would you help? Could you try use-context-selector only example to see if the issue is this or jotai?

I've updated the repo above with the counter example from the readme:
https://user-images.githubusercontent.com/4586894/103548812-a41f8980-4ea6-11eb-8d96-70663b46d41a.mov
With Preact, the counters aren't incrementing and after the first update, the other component is also rerendering.
(Compared to React: https://codesandbox.io/s/react-use-context-selector-xm235)

I've updated the repo above with the counter example from the readme:
https://user-images.githubusercontent.com/4586894/103548812-a41f8980-4ea6-11eb-8d96-70663b46d41a.mov
With Preact, the counters aren't incrementing and after the first update, the other component is also rerendering.
(Compared to React: https://codesandbox.io/s/react-use-context-selector-xm235)

The actual state in the state provider is updating correctly and the component is rerendering, but useContextSelector(context, (v) => v[0].count1) always returns 0.

The actual state in the state provider is updating correctly and the component is rerendering, but useContextSelector(context, (v) => v[0].count1) always returns 0.

This line executes
https://github.com/dai-shi/use-context-selector/blob/47795a18b3521458c0af01a1389a3bd18ed9a0b4/src/index.ts#L152
and useContextSelector is called again. After that, the reducer is called again with React. But with Preact, nothing happens:

React:

This line executes
https://github.com/dai-shi/use-context-selector/blob/47795a18b3521458c0af01a1389a3bd18ed9a0b4/src/index.ts#L152
and useContextSelector is called again. After that, the reducer is called again with React. But with Preact, nothing happens:

React:

Nice! Thanks for your investigation.
I was also reading the useReducer code in preact.
https://github.com/preactjs/preact/blob/d29d8580245eba65135f943f24f945cf95f01a1e/hooks/src/index.js#L136-L157
It will replace the reducer function in render, but not re-evaluate it. So, the preact behavior is different from react.
I can't come up with any solutions other than feature detection. It's regrettable, but let's see if it works.

Nice! Thanks for your investigation.
I was also reading the useReducer code in preact.
https://github.com/preactjs/preact/blob/d29d8580245eba65135f943f24f945cf95f01a1e/hooks/src/index.js#L136-L157
It will replace the reducer function in render, but not re-evaluate it. So, the preact behavior is different from react.
I can't come up with any solutions other than feature detection. It's regrettable, but let's see if it works.

https://github.com/mischnic/jotai-preact-demo
Your example seems to work fine with the new build.
diff --git a/package.json b/package.json
index abd0199..2f77f16 100644
--- a/package.json
+++ b/package.json
@@ -4,7 +4,7 @@
                "preact": "^10.5.9"
        },
        "resolutions": {
-               "use-context-selector": "file:./use-context-selector.tgz"
+               "use-context-selector": "https://pkg.csb.dev/dai-shi/use-context-selector/commit/29b09817/use-context-selector"
        },
        "scripts": {
                "start": "parcel index.html"

https://github.com/mischnic/jotai-preact-demo
Your example seems to work fine with the new build.
diff --git a/package.json b/package.json
index abd0199..2f77f16 100644
--- a/package.json
+++ b/package.json
@@ -4,7 +4,7 @@
                "preact": "^10.5.9"
        },
        "resolutions": {
-               "use-context-selector": "file:./use-context-selector.tgz"
+               "use-context-selector": "https://pkg.csb.dev/dai-shi/use-context-selector/commit/29b09817/use-context-selector"
        },
        "scripts": {
                "start": "parcel index.html"

Great! The state seems to update now, but there are still unnecessary rerenders:
https://user-images.githubusercontent.com/4586894/103634583-8e15d580-4f47-11eb-9e29-38b9f5fec71d.mov
Do you have a small example where Preact's useReducer behaves differently from React? Maybe they could fix that in Preact if we open an issue for this.

Great! The state seems to update now, but there are still unnecessary rerenders:
https://user-images.githubusercontent.com/4586894/103634583-8e15d580-4f47-11eb-9e29-38b9f5fec71d.mov
Do you have a small example where Preact's useReducer behaves differently from React? Maybe they could fix that in Preact if we open an issue for this.

https://overreacted.io/a-complete-guide-to-useeffect/#why-usereducer-is-the-cheat-mode-of-hooks
This article might help. I'm not sure if Preact should follow the React behavior.

https://overreacted.io/a-complete-guide-to-useeffect/#why-usereducer-is-the-cheat-mode-of-hooks
This article might help. I'm not sure if Preact should follow the React behavior.

That example works fine: https://codesandbox.io/s/preact-usereducer-cheat-hkhgv
At least for preact/compat, they usually strive for 100% compatibility.

That example works fine: https://codesandbox.io/s/preact-usereducer-cheat-hkhgv
At least for preact/compat, they usually strive for 100% compatibility.

Hmmm, I tried to reproduce the behavior in the codesandbox, without success. (Maybe the double reducer invocation behavior is specific to the combination with useContext??

Hmmm, I tried to reproduce the behavior in the codesandbox, without success. (Maybe the double reducer invocation behavior is specific to the combination with useContext??

@mischnic Thanks for the repro!
Meanwhile, I came up with another solution. This looks reasonable in code. Would you try if it works with preact?

@mischnic Thanks for the repro!
Meanwhile, I came up with another solution. This looks reasonable in code. Would you try if it works with preact?

Yes. Both use-context-selector itself and jotai work correctly now

Yes. Both use-context-selector itself and jotai work correctly now

Thanks. Let's merge and release this then.
Thanks again for raising this up and investigating in detail.

Thanks. Let's merge and release this then.
Thanks again for raising this up and investigating in detail.

Published: https://www.npmjs.com/package/use-context-selector/v/1.3.5

Published: https://www.npmjs.com/package/use-context-selector/v/1.3.5

Thanks!

Thanks!


Provide more accurate error message when using options from disabled plugins

          We should also consider how we can provide a better message in scenarios like this.

--summary-file-path is a known option, so we should be able to provide a more helpful message, like

To use <option name> you need to enable <name of plugin> plugin.

Originally posted by @garrytrinder in https://github.com/microsoft/m365-developer-proxy/issues/282#issuecomment-1621492626

The biggest consideration here is, that options are only known to plugins, and if a plugin is disabled, it's not loaded so we have no way of knowing which options it exposes, unless we leak responsibility and keep the list of known options, which goes against the modularity of plugins.

The biggest consideration here is, that options are only known to plugins, and if a plugin is disabled, it's not loaded so we have no way of knowing which options it exposes

I agree and whilst it would be great to match an option directly with a plugin, doing so would add additional complexity. That said, I think we could provide a hint or at least guide the user in the right direction.
In the case of #282, when the ExecutionSummaryPlugin is disabled, we throw an error and show the help output to list available options. To your point @waldekmastykarz, we don't list --summary-file-path and --summary-group-by as a valid options in the output as the plugin is not loaded.
Maybe we should consider adding a message after the errors, before the help information that asks have you not loaded a plugin? or something to that effect. We could also provide a short URL in the message to provide some extra guidance around enabling and disabling plugins which could be useful to new users.

Maybe we should consider adding a message after the errors, before the help information that asks have you not loaded a plugin? or something to that effect.
We could also provide a short URL in the message to provide some extra guidance around enabling and disabling plugins which could be useful to new users.

Great idea! Love it! Let's do that


afterInit event for yiiActiveForm

Q
A

Is bugfix?
no

New feature?
yes

Breaks BC?
no

Tests pass?
yes

Fixed issues
https://github.com/yiisoft/yii2/issues/12744

Thank you!


fix(docs): discovery property was missing, clean up code snippet

Issue # (if applicable)
/
Reason for this change
Code snippet in the docs was not working, it missed a discovery property.
Description of changes

Add a missing property
Delete an unnecessary await
Reorder the imports while at it.

Description of how you validated changes
/
Checklist

[ ] My code adheres to the CONTRIBUTING GUIDE

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

Thanks @lvansteenbergen !


Add user search by email address

Changes in the PR

Added the support to search the users by the email address.
Bumped the framework version to get the changes in [1].

[1] https://github.com/wso2/carbon-identity-framework/pull/4222

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/2866369529

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/2866369529
Status: success


replace deprecated nerd-fonts icon

with nerd-fonts v3.0.0 some material design icons were removed see Changelog. The new icon is an alternative.
You can check for deprecated icons with the nerdfix tool.
Best regards

Thanks for the notice! Just installed nerdfix with cargo and it works like a charm.
I did run the .tmux file through it and it pointed out the icon.
Will merge the commit ;)


Remove remnants of armhf and i386 from workflows

Proposed Changes
Remove the remnants of armhf and i386 from workflows from GitHub Actions workflows.
Also, it simplifies the linux/arm64/v8 platform to just linux/arm64 to align with the examples from https://docs.docker.com/build/building/multi-platform. It works the same (let me know if you disagree).
Related Issues
Refs #538

Good to know. I'm sure this will not change anything, but I don't really care about it, and for the sake of keeping it aligned to the upstream, I'm going to revert it then.
https://github.com/hassio-addons/workflows/blob/0a1ecb299cbcd4a2cad810b8ca692dbc4831ff34/.github/workflows/addon-ci.yaml#L160

Not sure if we should do this, the if statements do not really hurt, and might actually help, if for whatever reason we bring back the other Archs.
What do you think?

Let's add it, you are right I dont see the Arch to come back, so thanks a lot @felipecrs

Sorry the delay, but I would be ok with both options as well.


Add Node.js sample for Multi-lingual generation and language fallback policy

The section Multi-lingual generation and language fallback policy only has an sample for dotnet. I think that the docs would really benefit from an example in Node.js. If others are interested I got it working after some trial and error.
In your Bot and/or Dialog file (or other files where you use LG) add:
const { Templates, MultiLanguageLG } = require('botbuilder-lg');
In your constructor add:
// Create Templates for all locales (must use absolute path)
const defaultLg = Templates.parseFile(__dirname + '/lg/Main.lg'); // default is english in my case
const svLg = Templates.parseFile(__dirname + '/lg/Main.sv-SE.lg'); // swedish translations

// Create a Map with Templates for all locales
const lgTemplatesPerLocale = new Map<string, string>();
lgTemplatesPerLocale.set("", defaultLg);
lgTemplatesPerLocale.set("sv-SE", svLg); // Note, language code must match exactly what your client is using!

// Create a Multi Language LG using the Templates in the Map
this.lgGenerator = new MultiLanguageLG(lgTemplatesPerLocale);

The constructor in MultiLanguageLG can take a Map with file path to the LG file as a string (filePerLocale), instead of a Tampletes object, but I never managed to get it working. I am unsure if absolute or relative file paths must be used. The reason i use Templates.parseFile is that an error shows in the console if the path is not correct (the lg file can not be found). This helps making sure the LG files are found or not. No error messages are printed when using a filePerLocale Map.
So, doing like this is not working:
const lgFilesPerLocale= new Map<string, string>();
lgFilesPerLocale.set("", __dirname + '/lg/Main.lg');
lgFilesPerLocale.set("sv-SE", __dirname + '/lg/Main.sv-SE.lg');
this.lgGenerator = new MultiLanguageLG(lgFilesPerLocale);

No useful error message is displayed in console, but:
(node:22396) UnhandledPromiseRejectionWarning: TypeError: Cannot perform 'set' on a proxy that has been revoked
    at adapter.sendActivities.then (D:\Utveckling\Teams Apps\moodle-stats\node_modules\botbuilder-core\lib\turnContext.js:339:36)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:22396) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a
catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:22396) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Next step is to call generate on the lgGenerator when you want your localized messages:
this.lgGenerator.generate('YourTemplateName', yourDataToTheTemplate, context.activity.locale);
If you do not need to send data to the template use "" (using null did not work, generated an error message in console):
this.lgGenerator.generate('YourTemplateName', "", context.activity.locale);
Exampel of sending an Activity:
await context.sendActivity(ActivityFactory.fromObject(this.lgGenerator.generate("WelcomeCard", userProfile, context.activity.locale)));
Note! Be sure to check what context.activity.locale contains and then you must match exactly this value in the Map. For example in my MS Teams context.activity.locale contains sv-SE. If I in the map use:
lgTemplatesPerLocale.set("sv", svLg);
It will not work. Neither will:
lgTemplatesPerLocale.set("sv-se", svLg);
Notice the difference in se and SE. This is strange as I thoug language tags would be handled in the same way as localization for the manifest.json file (localizationInfo). At the page, linked below, they "strongly recommended to provide top-level, language-only translations in your manifest ('en' instead of 'en-us') and only provide region-level overrides for the few strings that need them".
https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/build-and-test/apps-localization#localizing-the-strings-in-your-app-manifest
[enhancement]

@roberi We are waiting for #2484 to be merged that addresses this issue. Please try again once the master branch gets updated.


[Event Request] Table 901 - Assembly Line - OnBeforeAutoReserve

Hi AL-Team,
can you please add the following publisher with handled pattern to AutoReserve?
 procedure AutoReserve()
    var
        ReservMgt: Codeunit "Reservation Management";
        FullAutoReservation: Boolean;
        Handled: Boolean;
    begin
        // NEW >>>>
        OnBeforeAutoReserve(Rec, Handled);
        if Handled then
            exit;
        // NEW <<<<
        if Type <> Type::Item then
            exit;

        TestField("No.");
        if Reserve <> Reserve::Always then
            exit;

        if "Remaining Quantity (Base)" <> 0 then begin
            TestField("Due Date");
            ReservMgt.SetAssemblyLine(Rec);
            ReservMgt.AutoReserve(FullAutoReservation, '', "Due Date", "Remaining Quantity", "Remaining Quantity (Base)");
            Find;
            if not FullAutoReservation and (CurrFieldNo <> 0) then
                if Confirm(Text001, true) then begin
                    Commit;
                    ShowReservation;
                    Find;
                end;
        end;
    end;

    [IntegrationEvent(false, false)]
    local procedure OnBeforeAutoReserve(var Rec: Record "Assembly Line"; var Handled: Boolean)
    begin
    end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Add Tests for Signal package.

What type of PR is this?
/kind feature
What this PR does / why we need it:
New tests are added to the signal package.
TestSetupSignalContext - TestSetupSignalContext verifies that the SetupSignalContext function correctly handles shutdown signals.
TestSetupSignalContextTwice - // TestSetupSignalContextTwice verifies that calling SetupSignalContext twice panics.
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?
NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
NONE

/ok-to-test


fixes on enum generation, multiline comments support and swagger v2 body params

The branch contains the following fixes:

In swagger v2 generation, the body annotation was previously generated with the name as string parameter like this:
@Body('name') which breaks the generated code because the body annotation does not accept a string parameter. It is now generated as @Body(). #53
Added support for multiline description comment. Previously a description string of "First line\nNext line" would generate a comment for the first line only, now every line will be commented. #54
Fixed default value for enums passed as query parameters. Previosly the generated code was @Query('unit') Unit unit = CELSIUS but this is invalid in dart syntax, therefore enums default values are now generated as follows: @Query('unit') Unit unit = Unit.celsius #56
Fixed the generation of enums of type string but having items starting with a number (for example a value could be "404NotFound"). The generation now follows the same rule that is applied in case of integer enums. #55

Still generate @Body('string'), my swagger file is swagger.

Still generate @Body('string'), my swagger file is swagger.

Fixed in 1.10.2


Expose a JWKS Endpoint from the Gateway

Problem
We need to expose a JWKS endpoint from the Gateway in order to validate the backend JWTs. Also, the backend JWT token should include the kid claim.
Solution
Bring the current JWKS implementation to the gateway component. Use a configuration to decide weather or not the kid claim should be included in the backend JWT header.
Affected Component
APIM
Version
4.1.0
Implementation
No response
Related Issues
No response
Suggested Labels
No response

Waiting for this implementation to test further.

We can use the following config under deployment.toml to add/remove the kid claim from the backend JWT. Unless this use_kid_property is explicitly set to false, the backend JWT header will include the kid claim.
[apim.jwt]
use_kid_property = true

You can invoke the JWKS endpoint using the following URLs:

https://<host>:8243/jwks for super tenant
https://<host>:8243/t/<tenant domain>/jwks for tenants


Email authentication typo results in poor UX

Versions

Google Play Services version: 10.0.1
FirebaseUI version: 1.1.1

Steps to reproduce:

Authenticate using email.
Sign out.
Try to authenticate again, using the same email, but "accidentally" introduce a typo (for example, replace an "n" with an "m" in the email address).

Observed Results:

Firebase correctly assumes this is a new email address, rather than a returning user; however, after the user realizes they have entered their email address incorrectly and proceeds to fix their mistake on the "new user" page, they must re-enter their name and password. This is not the problem. The problem is when they try to log in and then they are met with the error "an account already exists with that email address" rather than being authenticated using the correct email & password combination.

Expected Results:

After correcting their email address and entering their name and password, if their email address & password hash match a record in the user base, they should be authenticated as that user. If you really want to be paranoid, make it so that the name also has to match (ignoring case, probably) the name already on record for that account.

@samtstern @togic8  This was a conscious decision https://github.com/firebase/FirebaseUI-Android/pull/447#discussion_r91544515 to make the UX feel less janky, but I'm wondering if we could compromise and forward the user along to the sign in page while showing a toast or something.
https://github.com/firebase/FirebaseUI-Android/blob/master/auth/src/main/java/com/firebase/ui/auth/ui/email/RegisterEmailFragment.java#L288


Edit button on student details page post search does not work.

Bug Description
When an instructor level user presses the edit button on a students page, it fails to move to the edit page. (Edit button does not work.)
To Reproduce

Click Board Links
Click Search
Enter student, name press Submit
Click on student's last name
Press Edit next to students name

Expected behavior
Clicking edit should proceed to the next page to allow editing of the students name and safety class date.
Screenshots
If applicable, add screenshots to help explain your problem.
Smartphone (please complete the following information):

Device: Samsung Note 10+ (SM-N975U)
OS: Android 11
Browser Chrome
Version 97.0.4692.70

Resolved js issues that caused this problem.


Traffic Light Protocol 2.0

Background
The Traffic Light Protocol (TLP) 2.0 is a widely used information sharing standard that indicates how and with whom information can be shared. Currently, the Unified Cyber Ontology's marking vocabulary lacks support for TLP 2.0 markings. Adding a TrafficLightProtocol_2_0 class as a subclass of marking:ReleaseToMarking will enable proper classification and handling of information according to TLP 2.0 standards.
Sources

TLP FIRST Standards Definitions and usage Guidance - Version 2.0
TLP 2.0 Use Cases
TPL 2.0 Definitions and Usage from DHS CISA
CASE Ontology
Unified Cyber Ontology
National Council of ISACs

Extensions Beyond TLP Standard
This proposal includes two extensions beyond the official TLP 2.0 specification:

validUntil Property: Enables time-bound access control

Optional extension for automated handling
Not part of official TLP specification
Can be omitted for strict TLP compliance

Community Restrictions: Formalizes sharing boundaries

Extends TLP:GREEN semantics
Optional enhancement for precise control
Can be omitted for strict TLP compliance

External Namespace Dependencies
This proposal relies on several external ontologies:

Unified Cyber Ontology (UCO)

uco-core: Core objects and properties (e.g., objectMarking, createdTime)
uco-observable: Cyber observable objects for threat detection
uco-types: Common data types and structures
Source: UCO GitHub

CASE

case-investigation: Investigation records and provenance
relationship: Entity relationships and sharing agreements
Source: CASE GitHub

Dublin Core Terms

dcterms: Metadata properties for versioning and dates
Source: DCMI Namespace

SKOS

skos: Semantic concept definitions and documentation
Source: SKOS Reference

Legacy TLP 1.0 Definition
Traffic Light Protocol 1.0 (TLP 1.0) is a legacy marking scheme that is no longer supported (deprecated). There is a large volume of cyber domain data marked with TLP 1.0. For migration support, we define the TLP 1.0 class and its usage but mostlyfocus on the TLP 2.0 class and its usage in this change proposal.
We can chose to define the TLP 1.0 class and its usage as a subclass of marking:ReleaseToMarking or as a separate class. The choice is made to define the TLP 1.0 class as a subclass of marking:ReleaseToMarking.
# TLP 1.0 Class Definition
marking:TrafficLightProtocol_1_0
    a owl:Class ;
    rdfs:subClassOf marking:ReleaseToMarking ;
    rdfs:label "Traffic Light Protocol 1.0 Marking"@en ;
    rdfs:comment "Legacy TLP 1.0 marking class, maintained for migration support."@en ;
    owl:versionInfo "1.0" ;
    owl:deprecated true .

# TLP 1.0 Property Definition (using string literals)
marking:tlpLevel_1_0
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_1_0 ;
    rdfs:range xsd:string ;
    rdfs:comment "Legacy string-based TLP level property."@en ;
    owl:deprecated true .

# Example TLP 1.0 Usage
_:example1
    a marking:TrafficLightProtocol_1_0 ;
    marking:tlpLevel_1_0 "WHITE" .

_:example2
    a marking:TrafficLightProtocol_1_0 ;
    marking:tlpLevel_1_0 "AMBER" .

Requirements
Requirement 1
Create a new class marking:TrafficLightProtocol_2_0 as a subclass of marking:ReleaseToMarking to represent TLP 2.0 marking classifications.
Requirement 2
Define the four TLP 2.0 marking values (RED, AMBER, GREEN, CLEAR) as individuals of the TrafficLightProtocol_2_0 class, including their definitions and sharing restrictions as specified in the TLP 2.0 standard.
Requirement 3
Define advanced properties for marking:TrafficLightProtocol_2_0 to support additional TLP 2.0 features, such as community restrictions and validUntil dates.
Requirement 4
Consider proposing a new class marking:TrafficLightProtocol_1_0 as a subclass of marking:ReleaseToMarking to represent TLP 1.0 marking classifications.
 Minor consideration should be given to:

Ensuring backward compatibility with any existing TLP marking implementations
Clear documentation to prevent confusion between TLP 1.0 and 2.0 markings

Competencies demonstrated
Competency 1
Scenario: An investigator needs to share technical investigation findings with different stakeholders while maintaining appropriate access controls based on TLP 2.0 markings.
Competency Question 1.1
Which pieces of evidence can be shared with first responders outside the organization?
Result 1.1
Evidence marked with TLP:AMBER can be shared with first responders who need to know, while TLP:RED items must remain within the organization.
Competency Question 1.2
What digital artifacts can be shared publicly from the investigation?
Result 1.2
Only artifacts marked as TLP:CLEAR can be shared publicly without restrictions.
Competency Question 1.3
Can Company A share TLP:AMBER threat intelligence with their contracted incident response provider?
Result 1.3
No, unless explicitly authorized by the originator through:

A standing agreement
A specific request
Instructions accompanying the intelligence

Competency Question 1.4
Can Company A share TLP:GREEN sector-specific threat intelligence with Company B?
Result 1.4
Yes, if both companies are part of the defined sector community. No, if either company is outside the specified sector.
Solution suggestion
Design Decisions and Rationale
1. Modeling Approach
We use a hybrid approach combining OWL and SKOS for different aspects of TLP 2.0:

OWL Classes and Properties (marking: namespace)

Used for the structural aspects of TLP markings
Defines how markings attach to objects
Handles validation and constraints
Example: marking:TrafficLightProtocol_2_0 class

Usage scenarios:

When creating or updating TLP markings
When validating marking constraints
When querying for marked objects

SKOS Concepts (vocabulary: namespace)

Contains the official FIRST TLP 2.0 definitions
Provides human-readable documentation
Enables semantic relationships between concepts
Example: vocabulary:TLPRed concept

Usage scenarios:

When displaying TLP definitions to users
When documenting marking usage
When mapping between different marking schemes

2. TLP Level Stability
The TLP 2.0 specification defines exactly four levels (RED, AMBER, GREEN, CLEAR) as a stable enumeration. This stability is reflected in our modeling:

Fixed Enumeration

The four levels are modeled as OWL individuals
SHACL constraints enforce this fixed set
Future TLP versions would be separate classes
IMPORTANT: These four individuals form a closed enumeration and MUST NOT be extended by third parties

Version Control

TLP 2.0 is a distinct class from TLP 1.0
Migration paths are explicitly defined
No dynamic level addition is supported

Data Migration Considerations

String to Individual Conversion
TLP 1.0 used string literals for levels:
# TLP 1.0 style
?marking marking:tlpLevel_1_0 "WHITE" .

TLP 2.0 uses typed individuals:
# TLP 2.0 style
?marking marking:tlpLevel marking:CLEAR .

Level Mapping
# Helper function to map old string levels to new individuals
BIND(
    CASE ?oldLevel
        WHEN "WHITE" THEN marking:CLEAR
        WHEN "RED" THEN marking:RED
        WHEN "AMBER" THEN marking:AMBER
        WHEN "GREEN" THEN marking:GREEN
        ELSE marking:CLEAR  # Default case
    END AS ?newLevel
)

Validation Steps
# Verify no invalid levels exist
SELECT ?marking ?invalidLevel
WHERE {
    ?marking a marking:TrafficLightProtocol_2_0 ;
             marking:tlpLevel ?invalidLevel .
    FILTER(?invalidLevel NOT IN (
        marking:RED, marking:AMBER,
        marking:GREEN, marking:CLEAR
    ))
}

3. Community Restrictions
The marking:communityRestriction property is formally defined as:
# Note: This is an extension beyond the official TLP specification
marking:communityRestriction
    a owl:ObjectProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:CommunityRestriction ;
    rdfs:label "community restriction"@en ;
    rdfs:comment "Specifies sharing restrictions for TLP:GREEN markings based on community membership."@en .

Usage patterns:

Sector Restrictions (using IRIs instead of strings)
?marking marking:communityRestriction marking:FinancialSector .

Geographic Restrictions (using IRIs instead of strings)
?marking marking:communityRestriction marking:EuropeanRegion .

2. TLP 1.0 to 2.0 Migration
Key changes from TLP 1.0 to 2.0:

TLP 1.0
TLP 2.0
Changes

WHITE
CLEAR
- Name change- Updated sharing semantics- Clearer public release criteria

GREEN
GREEN
- Enhanced community definition- Clarified sector boundaries

AMBER
AMBER
- Strengthened need-to-know requirements- Organization scope clarification

RED
RED
- Tightened disclosure restrictions- Added impact criteria

3. Property Justification
The validUntil property is introduced to support:

Time-bound information sharing agreements
Automatic declassification workflows
Incident response phase transitions
Compliance with data retention policies

While not part of the core TLP standard, this extension enables automated handling of temporal access controls.
Implementation steps:

Create new class marking:TrafficLightProtocol_2_0 as subclass of marking:ReleaseToMarking

Define four individuals representing TLP levels:

TLP:RED - Recipients may not share information with any parties outside of the specific exchange
TLP:AMBER - Recipients may only share information with members of their own organization who need to know
TLP:GREEN - Recipients may share information with peers and partner organizations within their sector or community
TLP:CLEAR - Information may be shared publicly without restrictions

Add appropriate documentation and examples

Create unit tests to validate proper usage of TLP 2.0 markings

The implementation will include proper rdfs:label and rdfs:comment annotations to document the meaning and usage of each marking level according to the official TLP 2.0 specifications.
Class Architecture Graph
graph TD
    A[marking:ReleaseToMarking] --> B[marking:TrafficLightProtocol_2_0]
    B --> C[marking:TLPLevel]
    C --> D[marking:RED]
    C --> E[marking:AMBER]
    C --> F[marking:GREEN]
    C --> G[marking:CLEAR]

    B -- marking:tlpLevel --> C
    B -- marking:validUntil --> H[xsd:dateTime]

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#bbf,stroke:#333,stroke-width:2px
    style C fill:#dfd,stroke:#333,stroke-width:2px
    style D fill:#fdd,stroke:#333,stroke-width:2px
    style E fill:#fed,stroke:#333,stroke-width:2px
    style F fill:#dfd,stroke:#333,stroke-width:2px
    style G fill:#dff,stroke:#333,stroke-width:2px

SPARQL Query Examples
Competency Question 1.1: Evidence Shareable with First Responders
Find evidence that can be shared with first responders outside the organization:
PREFIX marking: <https://ontology.unifiedcyberontology.org/uco/marking/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>
PREFIX case-investigation: <https://ontology.caseontology.org/case/investigation/>

SELECT DISTINCT ?evidence ?evidenceType ?createdTime
WHERE {
    # Get evidence items with their markings
    ?evidence a case-investigation:ProvenanceRecord ;
             uco-core:objectMarking ?marking ;
             a ?evidenceType ;
             uco-core:createdTime ?createdTime .

    ?marking a marking:TrafficLightProtocol_2_0 ;
             marking:tlpLevel ?level .

    # Filter for AMBER level (shareable with first responders who need to know)
    FILTER(?level = marking:AMBER)

    # Optional: Add temporal filter if needed
    # FILTER(?createdTime >= "2024-01-01T00:00:00"^^xsd:dateTime)
}
ORDER BY ?createdTime

Competency Question 1.2: Publicly Shareable Artifacts
Find digital artifacts that can be shared publicly:
PREFIX marking: <https://ontology.unifiedcyberontology.org/uco/marking/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>
PREFIX case-investigation: <https://ontology.caseontology.org/case/investigation/>

SELECT DISTINCT ?artifact ?artifactType
WHERE {
    ?artifact uco-core:hasMarking ?marking ;
             a ?artifactType .

    ?marking a marking:TrafficLightProtocol_2_0 ;
             marking:tlpLevel marking:CLEAR .

    # Optional: Filter out specific artifact types if needed
    FILTER NOT EXISTS {
        ?artifact a case-investigation:PersonalData .
    }
}

Competency Question 1.3: AMBER Sharing with Contractors
Check if TLP:AMBER intelligence can be shared with a contracted provider:
PREFIX marking: <https://ontology.unifiedcyberontology.org/uco/marking/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>

SELECT DISTINCT ?intelligence ?provider ?agreement
WHERE {
    # Get AMBER marked intelligence
    ?intelligence uco-core:objectMarking ?marking .
    ?marking a marking:TrafficLightProtocol_2_0 ;
             marking:tlpLevel marking:AMBER .

    # Check for explicit sharing agreements
    ?agreement a relationship:SharingAgreement ;
              relationship:source ?originator ;
              relationship:target ?provider ;
              relationship:permission "AUTHORIZED" .

    # Provider must be a contracted entity
    ?provider a relationship:ContractedService .

    # Optional: Check if agreement is still valid
    OPTIONAL {
        ?agreement uco-core:endTime ?endTime .
        FILTER(!BOUND(?endTime) || ?endTime > NOW())
    }
}

Competency Question 1.4: GREEN Sharing within Sector
Determine if TLP:GREEN intelligence can be shared between companies in the same sector:
PREFIX uco-marking: <https://ontology.unifiedcyberontology.org/uco/marking/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>
PREFIX uco-identity: <https://ontology.unifiedcyberontology.org/uco/identity/>
>

SELECT DISTINCT ?intelligence ?companyA ?companyB
WHERE {
    # Get GREEN marked intelligence with sector restriction
    ?intelligence uco-core:objectMarking ?marking .
    ?marking a uco-marking:TrafficLightProtocol_2_0 ;
             uco-marking:tlpLevel uco-marking:GREEN ;
             uco-marking:communityRestriction uco-marking:FinancialSector .

    # Check if both companies are in the financial sector
    ?companyA relationship:memberOf uco-marking:FinancialSector .
    ?companyB relationship:memberOf uco-marking:FinancialSector .

    # Ensure we're looking at different companies
    FILTER(?companyA != ?companyB)
}

These queries demonstrate how to:

Find AMBER-marked evidence shareable with first responders
Identify CLEAR-marked artifacts for public sharing
Verify sharing permissions for AMBER intelligence with contractors
Check sector-based sharing rules for GREEN intelligence

Solution suggestion (expanded)
Class Definition
URI
https://ontology.unifiedcyberontology.org/uco/marking/ReleaseToMarking/TrafficLightProtocol_2_0

Superclass
marking:ReleaseToMarking

Label
"Traffic Light Protocol 2.0 Marking"@en
Description
"A marking that indicates how and with whom information can be shared according to the Traffic Light Protocol version 2.0 standard."@en
Superclasses

marking:ReleaseToMarking

SHACL Shape Definition
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix marking: <https://ontology.unifiedcyberontology.org/uco/marking/> .
@prefix vocabulary: <https://ontology.unifiedcyberontology.org/uco/vocabulary/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# Base shape for TLP 2.0 markings
marking:TrafficLightProtocol_2_0Shape
    a sh:NodeShape ;
    sh:targetClass marking:TrafficLightProtocol_2_0 ;
    sh:property [
        sh:path marking:tlpLevel ;
        sh:datatype vocabulary:TLPLevelVocab ;
        sh:minCount 1 ;
        sh:maxCount 1
    ] ;
    sh:property [
        sh:path marking:tlpDefinition ;
        sh:datatype vocabulary:TLPDefinitionVocab ;
        sh:maxCount 1
    ] .

# Shape for validating community restrictions
marking:CommunityRestrictionShape
    a sh:NodeShape ;
    sh:targetClass marking:TrafficLightProtocol_2_0 ;
    sh:property [
        sh:path marking:communityType ;
        sh:datatype vocabulary:CommunityTypeVocab ;
        sh:maxCount 1
    ] ;
    # Only allow community restrictions for TLP:GREEN
    sh:sparql [
        sh:message "Community restrictions can only be applied to TLP:GREEN markings"@en ;
        sh:select """
            PREFIX marking: <https://ontology.unifiedcyberontology.org/uco/marking/>
            PREFIX vocabulary: <https://ontology.unifiedcyberontology.org/uco/vocabulary/>
            SELECT $this ?level
            WHERE {
                $this marking:communityType ?type .
                $this marking:tlpLevel ?level .
                FILTER(?level != "GREEN"^^vocabulary:TLPLevelVocab)
            }
        """
    ] .

# Shape for sector restrictions
marking:SectorRestrictionShape
    a sh:NodeShape ;
    sh:targetClass marking:TrafficLightProtocol_2_0 ;
    sh:property [
        sh:path marking:sector ;
        sh:datatype vocabulary:SectorVocab ;
        sh:maxCount 1 ;
        # Only allow sector if communityType is SECTOR
        sh:qualifiedValueShape [
            sh:path marking:communityType ;
            sh:hasValue "SECTOR"^^vocabulary:CommunityTypeVocab
        ]
    ] .

# Shape for geographic restrictions
marking:GeographicRestrictionShape
    a sh:NodeShape ;
    sh:targetClass marking:TrafficLightProtocol_2_0 ;
    sh:property [
        sh:path marking:geographicRegion ;
        sh:datatype vocabulary:GeographicRegionVocab ;
        sh:maxCount 1 ;
        # Only allow region if communityType is GEOGRAPHIC
        sh:qualifiedValueShape [
            sh:path marking:communityType ;
            sh:hasValue "GEOGRAPHIC"^^vocabulary:CommunityTypeVocab
        ]
    ] .

# Note: validUntil is an extension beyond the official TLP specification
marking:ValidUntilShape
    a sh:NodeShape ;
    sh:targetClass marking:TrafficLightProtocol_2_0 ;
    sh:property [
        sh:path marking:validUntil ;
        sh:datatype xsd:dateTime ;
        sh:maxCount 1
    ] .

Properties Table

Property
Type
Description
Range

marking:tlpLevel
ObjectProperty
The specific TLP 2.0 classification level
marking:TLPLevel

marking:validUntil
DatatypeProperty
Optional expiration date of the marking
xsd:dateTime

Property Shapes
marking:tlpLevel

Property Name: tlpLevel
Property Type: ObjectProperty
Description: "Specifies the TLP 2.0 classification level for information sharing"
Minimum Count: 1
Maximum Count: 1
Local Range: marking:TLPLevel
Global Range: marking:TLPLevel

marking:validUntil

Property Name: validUntil
Property Type: DatatypeProperty
Description: "Specifies the datetime until which this TLP marking is valid"
Minimum Count: 0
Maximum Count: 1
Local Range: xsd:dateTime
Global Range: xsd:dateTime

Vocabulary Definition
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vocabulary: <https://ontology.unifiedcyberontology.org/uco/vocabulary/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<https://ontology.unifiedcyberontology.org/uco/vocabulary/tlp>
    a owl:Ontology ;
    rdfs:label "TLP Vocabulary"@en ;
    owl:versionIRI vocabulary:2.0.0 ;
    dcterms:title "Traffic Light Protocol (TLP) Vocabulary"@en ;
    dcterms:description "Controlled vocabulary for Traffic Light Protocol (TLP) version 2.0 marking definitions and restrictions."@en .

vocabulary:TLPLevelVocab
    a rdfs:Datatype ;
    rdfs:label "TLP Level Vocabulary"@en ;
    rdfs:comment "Enumerated values for TLP 2.0 levels with their official definitions from FIRST."@en ;
    owl:equivalentClass [
        a rdfs:Datatype ;
        owl:onDatatype xsd:string ;
        owl:oneOf (
            "RED"^^vocabulary:TLPLevelVocab
            "AMBER"^^vocabulary:TLPLevelVocab
            "GREEN"^^vocabulary:TLPLevelVocab
            "CLEAR"^^vocabulary:TLPLevelVocab
        )
    ] .

vocabulary:TLPDefinitionVocab
    a rdfs:Datatype ;
    rdfs:label "TLP Definition Vocabulary"@en ;
    rdfs:comment "Official FIRST definitions for each TLP level."@en ;
    owl:equivalentClass [
        a rdfs:Datatype ;
        owl:onDatatype xsd:string ;
        owl:oneOf (
            "Not for disclosure, restricted to participants only. Sources may use TLP:RED when information cannot be effectively acted upon by additional parties, and could lead to impacts on a party's privacy, reputation, or operations if misused."^^vocabulary:TLPDefinitionVocab
            "Limited disclosure, restricted to participants' organizations. Sources may use TLP:AMBER when information requires support to be effectively acted upon, yet carries risks to privacy, reputation, or operations if shared outside of the organizations involved."^^vocabulary:TLPDefinitionVocab
            "Limited disclosure, restricted to the community. Sources may use TLP:GREEN when information is useful for the awareness of all participating organizations as well as with peers within the broader community or sector."^^vocabulary:TLPDefinitionVocab
            "Disclosure is not limited. Sources may use TLP:CLEAR when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release."^^vocabulary:TLPDefinitionVocab
        )
    ] .

vocabulary:CommunityTypeVocab
    a rdfs:Datatype ;
    rdfs:label "Community Type Vocabulary"@en ;
    rdfs:comment "Types of community restrictions that can be applied to TLP:GREEN markings."@en ;
    owl:equivalentClass [
        a rdfs:Datatype ;
        owl:onDatatype xsd:string ;
        owl:oneOf (
            "SECTOR"^^vocabulary:CommunityTypeVocab
            "GEOGRAPHIC"^^vocabulary:CommunityTypeVocab
            "ORGANIZATION"^^vocabulary:CommunityTypeVocab
        )
    ] .

vocabulary:SectorVocab
    a rdfs:Datatype ;
    rdfs:label "Sector Vocabulary"@en ;
    rdfs:comment "Enumerated values for sector-based community restrictions, aligned with critical infrastructure sectors."@en ;
    owl:equivalentClass [
        a rdfs:Datatype ;
        owl:onDatatype xsd:string ;
        owl:oneOf (
            "AUTOMOTIVE"^^vocabulary:SectorVocab
            "AVIATION"^^vocabulary:SectorVocab
            "CHEMICAL"^^vocabulary:SectorVocab
            "COMMUNICATIONS"^^vocabulary:SectorVocab
            "DEFENSE_INDUSTRIAL_BASE"^^vocabulary:SectorVocab
            "DOWNSTREAM_NATURAL_GAS"^^vocabulary:SectorVocab
            "ELECTIONS_INFRASTRUCTURE"^^vocabulary:SectorVocab
            "EMERGENCY_MANAGEMENT_AND_RESPONSE"^^vocabulary:SectorVocab
            "ELECTRICITY"^^vocabulary:SectorVocab
            "FINANCIAL_SERVICES"^^vocabulary:SectorVocab
            "FOOD_AND_AGRICULTURE"^^vocabulary:SectorVocab
            "HEALTHCARE"^^vocabulary:SectorVocab
            "INFORMATION_TECHNOLOGY"^^vocabulary:SectorVocab
            "MARITIME"^^vocabulary:SectorVocab
            "MARITIME_TRANSPORTATION_SYSTEM"^^vocabulary:SectorVocab
            "MULTI_STATE_GOVERNMENT"^^vocabulary:SectorVocab  # State, Local, Tribal, and Territorial Governments
            "NUCLEAR"^^vocabulary:SectorVocab
            "OIL_AND_NATURAL_GAS"^^vocabulary:SectorVocab
            "PUBLIC_TRANSIT"^^vocabulary:SectorVocab
            "REAL_ESTATE"^^vocabulary:SectorVocab
            "RESEARCH_AND_EDUCATION"^^vocabulary:SectorVocab
            "RETAIL_AND_HOSPITALITY"^^vocabulary:SectorVocab
            "SPACE"^^vocabulary:SectorVocab
            "SUPPLY_CHAIN"^^vocabulary:SectorVocab
            "SURFACE_TRANSPORTATION"^^vocabulary:SectorVocab
            "WATER"^^vocabulary:SectorVocab
        )
    ] .

vocabulary:GeographicRegionVocab
    a rdfs:Datatype ;
    rdfs:label "Geographic Region Vocabulary"@en ;
    rdfs:comment "Enumerated values for geographic-based community restrictions."@en ;
    owl:equivalentClass [
        a rdfs:Datatype ;
        owl:onDatatype xsd:string ;
        owl:oneOf (
            "NORTH_AMERICA"^^vocabulary:GeographicRegionVocab
            "SOUTH_AMERICA"^^vocabulary:GeographicRegionVocab
            "EUROPE"^^vocabulary:GeographicRegionVocab
            "ASIA"^^vocabulary:GeographicRegionVocab
            "AFRICA"^^vocabulary:GeographicRegionVocab
            "OCEANIA"^^vocabulary:GeographicRegionVocab
        )
    ] .

This vocabulary definition:

Follows UCO's pattern for controlled vocabularies
Uses rdfs:Datatype with owl:oneOf for enumerated values
Provides separate vocabularies for levels, definitions, and restrictions
Aligns sector vocabulary with established ISAC sectors
Includes geographic regions for regional sharing restrictions

RDF Implementation
@prefix marking: <https://ontology.caseontology.org/case/marking/> .
@prefix vocabulary: <https://ontology.unifiedcyberontology.org/uco/vocabulary/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

marking:TrafficLightProtocol_2_0
    a owl:Class ;
    rdfs:subClassOf marking:ReleaseToMarking ;
    rdfs:label "Traffic Light Protocol 2.0 Marking"@en ;
    rdfs:comment "A marking that indicates how and with whom information can be shared according to the Traffic Light Protocol version 2.0 standard."@en ;
    owl:imports <https://ontology.unifiedcyberontology.org/uco/vocabulary/tlp> ;
    owl:versionInfo "2.0.0" ;
    dcterms:issued "2024-03-20"^^xsd:date ;
    dcterms:replaces marking:TrafficLightProtocol_1_0 .

marking:tlpLevel
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:TLPLevelVocab ;
    rdfs:label "TLP level"@en ;
    rdfs:comment "Specifies the TLP 2.0 classification level for information sharing"@en .

marking:tlpDefinition
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:TLPDefinitionVocab ;
    rdfs:label "TLP definition"@en ;
    rdfs:comment "The official FIRST definition for this TLP level"@en .

marking:communityType
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:CommunityTypeVocab ;
    rdfs:label "community type"@en ;
    rdfs:comment "The type of community restriction (sector, geographic, or organization)"@en .

marking:sector
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:SectorVocab ;
    rdfs:label "sector"@en ;
    rdfs:comment "The specific sector for sector-based community restrictions"@en .

marking:geographicRegion
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range vocabulary:GeographicRegionVocab ;
    rdfs:label "geographic region"@en ;
    rdfs:comment "The specific geographic region for region-based community restrictions"@en .

marking:validUntil
    a owl:DatatypeProperty ;
    rdfs:domain marking:TrafficLightProtocol_2_0 ;
    rdfs:range xsd:dateTime ;
    rdfs:label "valid until"@en ;
    rdfs:comment "Specifies the datetime until which this TLP marking is valid"@en .

# Example Usage
_:example1
    a marking:TrafficLightProtocol_2_0 ;
    marking:tlpLevel "RED"^^vocabulary:TLPLevelVocab ;
    marking:tlpDefinition "Not for disclosure, restricted to participants only. Sources may use TLP:RED when information cannot be effectively acted upon by additional parties, and could lead to impacts on a party's privacy, reputation, or operations if misused."^^vocabulary:TLPDefinitionVocab .

_:example2
    a marking:TrafficLightProtocol_2_0 ;
    marking:tlpLevel "GREEN"^^vocabulary:TLPLevelVocab ;
    marking:communityType "SECTOR"^^vocabulary:CommunityTypeVocab ;
    marking:sector "FINANCIAL"^^vocabulary:SectorVocab .

Backward Compatibility
To ensure backward compatibility with existing TLP implementations, this proposal includes the following measures:

Version Identification

The class and vocabulary explicitly declare their version using owl:versionInfo
Both include dcterms:issued and dcterms:replaces to track versioning lineage
The vocabulary uses vann:preferredNamespacePrefix for consistent namespace handling

Migration Support

Systems can identify TLP version through the class URI and version info
Existing TLP 1.0 markings remain valid and can coexist with TLP 2.0
Automated migration tools can use dcterms:replaces relationships to update markings

Data Handling

TLP 1.0 markings are treated as valid but deprecated
Systems should prefer TLP 2.0 for new markings
Existing queries can be updated to handle both versions using UNION patterns

Example migration query:
PREFIX uco-marking: <https://ontology.unifiedcyberontology.org/uco/marking/>
PREFIX uco-core: <https://ontology.unifiedcyberontology.org/uco/core/>

# Update TLP 1.0 RED to TLP 2.0 RED
INSERT {
    ?observable uco-core:hasMarking [
        a uco-marking:TrafficLightProtocol_2_0 ;
        uco-marking:tlpLevel uco-marking:RED ;
        dcterms:created ?now
    ] .
}
WHERE {
    ?observable uco-core:hasMarking ?oldMarking .
    ?oldMarking a uco-marking:TrafficLightProtocol_1_0 ;
               uco-marking:tlpLevel "RED" .
    BIND(NOW() as ?now)
}

Community Engagement
This proposal will benefit from review and feedback from:

CASE Community

CASE Working Group members
Implementers of CASE-based systems
Digital forensics tool developers

TLP Stakeholders

FIRST (Forum of Incident Response and Security Teams)
CISA and other government cybersecurity organizations
Information sharing communities using TLP

Standards Bodies

OASIS CTI Technical Committee
STIX/TAXII community
Cyber threat intelligence platforms

@ajnelson-nist @sbarnum @eoghanscasey and @kchason here is a new proposal that I worked on to help us implement Traffic Light Protocol v2.0 as a subclass of UCO-marking:ReleaseToMarking. Appreciate any feedback you can provide.

@eoghanscasey

One remark, though I have not yet had time to go deeply through the proposal's details:
The Marking namespace has never had its concepts demonstrated in an example.  This file lists the IRIs of all concepts ever exercised in a CASE example to date, and the marking namespace does not appear within it.
I am reluctant to advance this proposal for a vote without a demonstration on instance data.
Unfortunately, I am unsure how the concepts in the marking space are to be used.  UCO avoiding rdfs:domain is detrimental here.
Committee discussions have touched on the marking namespace's concepts, but have left me thinking there is a significant variety of model structures that could be encompassed in "Markings" as intended by the original proposers (who predate my involvement in UCO):

The existence of an individual.
The identifier of an individual, but its existence may be releasable.

Working with this mode is technically possible by owl:sameAs, but there are nontrivial technology issues to work through with that modeling property.

A single property-assignment on an individual (analogous to either rdf:Statement or owl:Axiom).

This reduces to case 1 (existence of an individual) if UCO clarifies practices on reification of RDF properties by using core:Relationship.

A set of statements (analogous to a graph).

In RDF, I think this is workable in a quads model, but UCO works based on triples.  The transition between the two is non-trivial at least because SPARQL requires syntax adjustments to work in quads-based graphs.

I can think of a way to work around the "quads" need by heavy use of owl:Axiom.  But, reifying triples is pretty intense on graph-weight.  Any one (1) triple that needs to be annotated with a marking would induce a net five (5) triples.
# The statement to be marked.  (Original, 1 triple; net +0 triples.)
ex:A ex:b 1234 .

# The owl:Axiom.  (Induced, net +4 triples; fully automatically derivable.)
# (Note that OWL syntax rules require this to be a blank node.)
_:x
  a owl:Axiom ;
  owl:annotatedSource ex:a ;
  owl:annotatedProperty ex:b ;
  owl:annotatedTarget 1234
.

# The marking.  (Likely defined by user's organization or higher communal authority.)
kb:MarkingDefinition-da6afbcc-2475-4bc2-98f4-53cc847e2920
  a uco-marking:MarkingDefinition ;
  marking:definitionType "(example)" ;
  .

# The marking applied on the original statement.  (User-assigned, net +1 triple.)
_:x uco-marking:Marking kb:MarkingDefinition-da6afbcc-2475-4bc2-98f4-53cc847e2920 .

I fear without a demonstration of a marking showing the proposal's intent, and perhaps a demonstration of non-conformance with a marking scheme, this proposal is unlikely to be able to succeed.
I also suspect UCO's vocabularies will do sufficiently more harm than good in this case that they should be avoided.  Use of markings needs careful encoding of set-membership, and those sets can at times cease to exist, e.g. due to changes in legal authorities.  Using strings as a proxy for a class will fail to capture these details.
Any demonstration accompanying this proposal should have a small extension ontology that gets to a concrete sharing example.  The properties you proposed ending with ...Type should become abstract OWL classes in the Marking ontology or example-extension ontology, and the vocabulary strings should become concrete classes (probably in the example-extension ontology). There is likely a superclass that could go into the UCO Marking ontology, e.g., marking:Community could be a parent class of this hierarchy:
uco-marking:Community
\
 ex:BusinessSector (subclass of uco-marking:Community)
  \
    ex:FinancialSector (subclass of ex:BusinessSector)

It's not clear to me whether these sets should be encoded as OWL classes, or as some subclass of core:ContextualCompilation.
It would be a good exercise of this proposal's corner cases (and more generally, the Marking namespace) to devise an example of a release to some class that, for whatever reason, ceases to exist.  We should be able to identify that a release to that class is valid in a certain time period, but a release after the class ceases to exist is invalid.
For what it is worth, I do not believe I am introducing new fundamental complexity.  Modeling information marking is, at its core, a challenging problem.

Thanks for the feedback @ajnelson-nist.
Narrative Scenario
An investigator has a ProvenanceRecord (an investigative object as per CASE ontology references) that documents the acquisition of a data artifact from a disk image (https://digitalcorpora.org/corpora/disk-images/real-data-corpus). This artifact may contain sensitive threat intelligence. The investigator marks it TLP:GREEN, restricted to a certain business sector community (ex:FinancialSector). The marking allows sharing within that sector until a specified date, aligning with TLP 2.0 specifications.
I am happy to see your community subclassing idea above as we could us uco-marking:Community broadly to define various communities' marking standards and potentially let's us implement many different marking schemes. I chose TLP as it is broadly used in the cyber threat intelligence community. Building on your example:
uco-marking:Community
\
 ex:BusinessSector (subclass of uco-marking:Community)
  \
    ex:FinancialSector (subclass of ex:BusinessSector)

I created an example based on the scenario above:
`@prefix ex: <http://example.org/ontology#> .
@prefix marking: <https://ontology.unifiedcyberontology.org/uco/marking/> .
@prefix core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix case-investigation: <https://ontology.caseontology.org/case/investigation/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

#####################################################
# Community Modeling as Classes
#####################################################

ex:Community a owl:Class ;
    rdfs:label "Community"@en ;
    rdfs:comment "A grouping or set of entities that share some common interest."@en .

ex:BusinessSector a owl:Class ;
    rdfs:subClassOf ex:Community ;
    rdfs:label "Business Sector"@en ;
    rdfs:comment "A community defined by an industry sector."@en .

ex:FinancialSector a owl:Class ;
    rdfs:subClassOf ex:BusinessSector ;
    rdfs:label "Financial Sector"@en ;
    rdfs:comment "Organizations in the financial industry."@en .

#####################################################
# Example Marking Instance - TLP:GREEN
#####################################################

:greenMarkingForFinancialSector
    a marking:TrafficLightProtocol_2_0 ;
    marking:tlpLevel "GREEN"^^<https://ontology.unifiedcyberontology.org/uco/vocabulary/TLPLevelVocab> ;
    marking:communityRestriction ex:FinancialSector ;
    marking:validUntil "2025-01-01T00:00:00Z"^^xsd:dateTime ;
    rdfs:comment "TLP:GREEN data may be shared within the Financial Sector community."@en .

Linking to a ProvenanceRecord from the References
From the references you provided in https://github.com/ajnelson-nist/CASE-Examples-QC/blob/2a521d863d943ceef7c3e4e1a7b63f0f786935d2/tests/used_concepts.txt , we have:

https://ontology.caseontology.org/case/investigation/ProvenanceRecord
https://digitalcorpora.org/corpora/disk-images/real-data-corpus (possible source artifact)
https://ontology.caseontology.org/case/investigation/Investigation (potentially relevant class to show context)
https://ontology.unifiedcyberontology.org/uco/core/objectMarking (core property to attach markings—if defined in UCO core or marking namespaces)
We will assume core:objectMarking is the property used to link a marking to an object. (In UCO, the current property commonly used is uco-core:objectMarking. If needed, this might be adjusted to the correct namespace.)

@prefix ex: <http://example.org/ontology#> .
@prefix marking: <https://ontology.unifiedcyberontology.org/uco/marking/> .
@prefix core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix case-investigation: <https://ontology.caseontology.org/case/investigation/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

#####################################################
# Example Provenance Record
#####################################################

:provenanceRecord1
    a case-investigation:ProvenanceRecord ;
    core:objectMarking :greenMarkingForFinancialSector ;
    rdfs:label "Disk Image Provenance Record"@en ;
    rdfs:comment "Provenance record for an artifact derived from real-data-corpus disk images."@en ;
    dcterms:source <https://digitalcorpora.org/corpora/disk-images/real-data-corpus> ;
    dcterms:created "2024-06-15T12:00:00Z"^^xsd:dateTime .

:provenanceRecord1 is an instance of case-investigation:ProvenanceRecord.
It is linked to the :greenMarkingForFinancialSector marking via core:objectMarking.
The source of this record is https://digitalcorpora.org/corpora/disk-images/real-data-corpus, which appears in the references from used_concepts.txt.
This shows how the marking interacts with a real investigative object that references known datasets, aligning better with previously used concepts.

Query Demonstration
A SPARQL query to find all provenance records that can currently be shared with members of the financial sector (before the validUntil date):
PREFIX marking: <https://ontology.unifiedcyberontology.org/uco/marking/>
PREFIX core: <https://ontology.unifiedcyberontology.org/uco/core/>
PREFIX case-investigation: <https://ontology.caseontology.org/case/investigation/>
PREFIX ex: <http://example.org/ontology#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?record
WHERE {
    ?record a case-investigation:ProvenanceRecord ;
            core:objectMarking ?marking .
    ?marking a marking:TrafficLightProtocol_2_0 ;
             marking:tlpLevel "GREEN"^^<https://ontology.unifiedcyberontology.org/uco/vocabulary/TLPLevelVocab> ;
             marking:communityRestriction ex:FinancialSector ;
             marking:validUntil ?validUntil .

    FILTER(NOW() < ?validUntil)
}

This query ensures we only find records that are shareable under TLP:GREEN restrictions within the financial sector and before the validUntil date has passed.
Handling Community Deactivation
If, in the future, ex:FinancialSector ceases to exist or is deprecated:
ex:FinancialSector
    owl:deprecated true ;
    rdfs:comment "This sector is no longer recognized as a valid community."@en .

Then a reasoner or compliance checking script might determine that :greenMarkingForFinancialSector no longer references a valid current community. Administrators would have to update the marking or remove it. This demonstrates how modeling communities as classes allows the ontology to evolve over time and makes the validity of marks contingent on the ontology’s state.
Conclusion
This revised demonstration:

Integrates references that appeared in the used_concepts.txt file, such as case-investigation:ProvenanceRecord and https://digitalcorpora.org/corpora/disk-images/real-data-corpus.
Shows instance-level data using the core:objectMarking property to attach a TLP:GREEN marking to a real investigative record.
Highlights how TLP 2.0 markings could be managed and queried in a realistic scenario, while still allowing the ontology to evolve (e.g., deprecating a community class).


Added Black for Python

This PR, added the support for Black, the uncompromising Python code formatter.
It is directly from the Python team.
This plugin format the python code. Very simple but very strong.

split contribution in N PR pls


Initial logs directory should be auto-created

java.lang.RuntimeException: java.nio.file.NoSuchFileException: logs/scenario_20201206_000218_304.js
When the logs directory is manually created, there is no error. This is a functional regression from the logging system changes.

fixed in rc branch


GH actions ubuntu 20 04

resolves #4136. Includes

[x] changes ubuntu-16.04 to ubuntu-20.04
[x] updated bazel install for Ubuntu 20.04
[x] sets specific version tag for windows

@95-martin-orion good catch! Updated the tag in stale.yml


CDN, Debug and Caching

I am bootstrapping openui5 via
src="https://openui5.hana.ondemand.com/resources/sap-ui-core.js"
id="sap-ui-bootstrap"
data-sap-ui-theme="sap_fiori_3"
data-sap-ui-libs="sap.m"
data-sap-ui-async='true'

When I look at the network traces, I believe that

In version 1.69 the debug files had been loaded. When I tested just now with 1.70 this was not the case.
The cache control is set to a low value with max-age=900seconds for most files.

Is this by accident or for a good reason? I can't think of a single reason why the max-age shuould be that low on a file that does never change.
Mind to validate and fix?

Hi @wernerdaehn ,
Thank you for sharing this finding. I've created an internal incident<PHONE_NUMBER>. The status of the issue will be updated here in GitHub.
Regards,
Hristo

Hi @wernerdaehn ,
The issue is no longer relevant.
OpenUI5 1.69 and 1.70 are removed from SAP CDN.
Best Regards,
Hristo