Closed stuartasutton closed 6 years ago
This was intentional, since we didn't want to require organizations to update the records about themselves every time they publish a new credential.
OK, but how do we do it so that it doesn't mess up the linked data? In the wild, it doesn't make a lot (any) sense. This is where declaring owns/ownedBy and offers/offeredBy as owl:inverseOf is handy in an RDF context. In a RDF datastore that would mean that there would be no need to update the organization record, the additional, implied triple would simply be added based on the inverse declaration.
Couldn't properties explicitly declared as owl:inverseOf
in CTDL be handled automatically in the CER; e.g.,
offeredBy==owl:inverseOf==>offers
A==offeredBy==>B (explcit)
B==offers==>A (implied from the explicit and automatically provided by CER)
We should create a list of properties that need to be explicitly indicated as inverseOf and the properties they are inverses of.
I agree. Such a list would not be long and should not tread where the likelihood exists that inferring the inverse would/could be problematic.
Of course, this might present problems with signed entities that get additional statements added through inference from inverse declarations. E.g., consider where a new credential is added to an organization's repertoire and the new credential uses the ceterms:ownedBy
to point to the owning organization.
Credential==ownedBy==>Organization
(explicit triple)
If ceterms:owns
is declared as inverse of ceterms:ownedBy
in the schema , a triple would be automatically added to the organization's description.
Organization==owns==>Credential
(implied triple)
Per our 8/8/2017 conversation: We would like to accomplish the following:
A candidate list of properties to be declared and treated as owl:inverseOf
or schema.org/inverseOf
:
Direct | Inferred |
---|---|
hasPart | isPartOf |
ownedBy | owns |
offeredBy | offers |
worksFor | employee |
We might hold on the last one and doubt the wisdom of the third one.
To include "reverse" properties in a JSON-LD @context
, see: https://json-ld.org/spec/FCGS/json-ld/20130328/#reverse-properties
Assuming we acknowledge these properties and their in inverse relationship. How can this be enabled in the registry such that we achieve the goal outlined at the top of this issue--i.e., Organizations that own things can point to those things in the registry etc. What are the impediments?
Currently that data would have to be published as part of the organization record, meaning it's up to whoever is publishing the data to figure out and include those relationships. Since records in the registry can't be modified after being published, the next best thing would be to query the registry for what amounts to: "give me all x where ceterms:owner = [ctid]"
This would enable the consumer to get a list of credentials, assessments, learning opportunities, etc., where the owner property is the CTID for the organization in question. It technically has no reliance on the property having any inverse declaration, but it should achieve the desired effect.
As usual, Nate, I'm looking at this data in the wild. Person comes across an RDF description of Brandman and there is not a clue about it's credentials. : -) linked data, not queried data. Again, we butt up against signed records. As usual, I'm concerned with the export of the data as RDF. If people out there can glue together the record by querying the registry, why can't the registry do that as it preps the description encoding for display and export.
The registry would need to offer some service or endpoint that returns records that have been augmented with relevant data like that. In essence performing the query on the user's behalf internally but offering that as an ordinary URL on the public-facing side. The user would know that they are accessing a record whose signature is invalid but which is at least coming from the registry itself.
As for the signature mechanism itself, it seems we're stuck with it - though it may be worth bringing it up to/with @science to see if it is as necessary now as it seemed when the project began (particularly given the conversation our team had with his team yesterday regarding how entities actually get data into the registry). Steve, if you can chime in, we would appreciate it.
This has been added to the publisher.
I've attached the json for two CredentialOrganization grabbed from the "Registry Info": Board of Cerfified Safety Professionals (BCSP) and Western Governors University. They have .txt file extensions because of github limitations. I've also include the BCSP json below.
Note that while the BCSP has 8 credentials and the Western Governor 1, the json for neither organization references any credentials that it owns or offers. In other words, there are no properties linking these organizations to their credentials. Their credentials link to their organizations through properties like
ceterms:ownedBy
and `ceterms:offeredBy', but an organization description found on the open web would have no means of identifying it's credential(s).BCSP-CredentialOrganization-json.txt WestGov-CredentialOrganization-json.txt