-
Notifications
You must be signed in to change notification settings - Fork 8
The JSON context is incomplete and has other issues #508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I haven't checked every property but the pattern seems to be that the range of those properties is either a Competency or a CompetencyFramework, rather than a URI. Currently (perhaps incorrectly) the code that generates the context file will leave these out so as to accommodate use of both an At one point we did include such properties in the context file, declared as being |
Nate a range of Competency or CompetencyFramework IS a URI. Nate please precisely define "pointer object" (in the context of the Registry)...bnodes of the types constituting what you call top-level? |
Yes. In other words, we have to allow both of these:
or, to put it another way:
If we specify that
and would have no way to indicate objects that don't have URIs. This applies outside of the Registry, though the only "real" use cases we have so far are Registry-centric. So we can't restrict the context to only allow URI strings for properties that point to classes of objects where such objects may not have URIs to point to without breaking the Registry. |
Per our 1/30/2018 conversation: The solution to this is, in hindsight, quite obvious and I'm not sure how we missed it in the first go-around. Essentially we:
|
@cwd-mparsons @stuartasutton @jkitchensSIUC this one is a big issue, similar to language maps in scale/impact, because it affects all pointer object implementations. So it impacts:
|
Nate, for the sake of complete documentation, where you state "Use blank node IRIs as the @id property for all reference/pointer objects", you referred to bnode identifiers in the following convention using an underscore:
Thus the properties listed at the top of this message can be included in the This is a very, very significant issue and should be given the highest priority we can muster given all there is to do. |
Exactly. It will also impact the JSON validation in the sense that things will need to be sent to the registry wrapped in a That would likely have ended up happening anyway for competency frameworks, though, so perhaps it will at least help our records be/look more consistent. |
Yes, the One other small note, I simply used a uuid and not the ctid variant (ce-) in the example since the actual value doesn't matter downstream because when other parsers get hold of a graph with bnodes, they substitute their own favorite form for bnode identifier. The result is the same, but the nodeID is inevitably different. |
So we would effectively go from:
to:
|
Updated implementation steps:
|
This has been solved and will be handled by the implementation of #521. |
Uh oh!
There was an error while loading. Please reload this page.
@siuc-nate, the CEASN context file at http://credreg.net/ctdlasn/schema/context/json is quite incomplete resulting in incorrect outcomes with the CASS data. My inventory (please double check) shows the following needing definition in the context file, otherwise, we get a lot of URIs handled as strings as opposed to things:
The context file should contain everything needed for JSON data both inside and outside the CER; so, it should be a compete context for the CTDL schema.
ALSO
Also, please take a look at issue Reuse of CTDL properties and concept schemes in CE-ASN data #495 because it impacts the context file; and
We need to change the
weight
property toxsd:string
in the definition table that still hasxsd:float
. We need to be able to express things like "23%". Values for this property are not subject to mathematical manipulation.The text was updated successfully, but these errors were encountered: