PURLs for use as URIs for credentials, organization, learning opps, and assessment profiles

[mparsons1953]

@stuartasutton @science re; Nov. 8th discussion on PURLS for credentials, and organizations primarily, but would include, assessment profiles and learning opportunities We seemed to have consensus that a URI for credentials, etc could be created by the registry, and stored in the envelope metadata. The preference would have been to add to identifiers section of the envelope resource. However Steve rightly felt the registry should not be injecting data into the envelope resource.

The URI added to the metadata (actual location is TBD), would be simple without the context of the resource type (credential, etc). The URI would be the URL of the document in the registry. The format would be something like: http://www.ce-registry.com/ctid/urn:ctid:12345678-1234-1234-1234-1234567890ab

We talked about the use of PURLs for this URI, but don't think we made a decision. First: Should we use PURLs? Second: what would the pattern be?

Suggested could be:

/ctdl/ctid/

The PURL target would be something like:

http://www.ce-registry.com/ctid/

An implementation of the latter could be:

http://purl.org/ctid/urn:ctid:12345678-1234-1234-1234-1234567890ab

The latter is a title redundant (ctid appearing twice). An alternate could be:

http://purl.org/ctid/12345678-1234-1234-1234-1234567890ab The PURL target would then be a partial something like :

http://www.ce-registry.com/ctid/urn:ctid:

[stuartasutton]

A few observations/preferences:

1. Mike, you state: "We seemed to have consensus that a URI for credentials, etc could be created by the registry, and stored in the envelope metadata. The preference would have been to add to identifiers section of the envelope resource. However Steve rightly felt the registry should not be injecting data into the envelope resource." I understand the rationale for injecting data into the envelope resource and not into the resource metadata; but, I note that the purpose of including the URI at all is to expose it to 'people' so they can use it to reference (link to) the resource in their own metadata descriptions. Doesn't putting it in the envelope defeat that purpose since someone looking at the record display wouldn't see it? To the Linked Data world, this URI is THE identifier--literally called the "name" of the resource in RDF.
2. I see no reason for using PURLs for resources other than properties, classes (including concept (vocabulary) classes--i.e., PURLS for Credential, CredentialOrganizations etc--given a social commitment to long-term maintenance of a namespace like http://www.ce-registry.com. (Would it be .com and not .org? Really? Bad choice since nothing is gained and much lost)). If these resources have PURLs, I'd prefer seeing something that said nothing about "ctdl" and was more Credential Engine Registry-ish like with "resource" being the bucket of all credential context entities (Credential, CredentialOrganization etc.):

http://purl.org/cer/resource/12345678-1234-1234-1234-1234567890ab or (using full URN) http://purl.org/cer/resource/urn:ctid:12345678-1234-1234-1234-1234567890ab

[jeannekitchens]

@mparsons1953 make sure the one document with all PURL planning is linked here.

[siuc-nate]

Refer to the PURL planning document: https://docs.google.com/document/d/19HPCUKQFZJnlLhTPqxkb3NUJwww9yujQUS0ssv-4Jd8/edit#

[siuc-nate]

What property would hold this generated URI?

[siuc-nate]

Per our conversation with Stuart on 11/15/2016:

Create a property: cerid (credential engine registry identifier) Domain: Credential, AssessmentProfile, LearningOpportunityProfile, Organization Range: xsd:anyURI Definition: The URI for this resource within the Credential Engine Registry. Usage Note: This is generated by concatenating the Credential Engine Registry's URL partial and the resource's CTID.

[siuc-nate]

Alerting @stuartasutton @science @mparsons1953 @jkitchensSIUC to this one, by request. Please see the previous post in this thread.

[stuartasutton]

I would also add to the domain list the ctdl:ConditionsProfile. There is every likelihood that 3rd parties will want to linked to instances of ctdl:ConditionProfile. E.g.:

[siuc-nate]

@stuartasutton I don't quite understand the use case - why would anything need to point to a Credential's condition profiles, other than that credential itself?

In the case above, I could see the value in having the learning opportunity indicate that it is preparationFor the Credential, and isSimilarTo the Learning Opportunity, but I do not see any useful value in pointing some external entity to a Credential's conditions. ConditionProfiles, at least as I have always conceptualized them, are integral to the Credential to which they are conditions for - it makes sense to reference their Credential, but not the Conditions themselves.

[stuartasutton]

If they want to assert that it fulfills a condition...they might well want to.

On Tue, Nov 15, 2016 at 1:50 PM, siuc-nate notifications@github.com wrote:

@stuartasutton https://github.com/stuartasutton I don't quite understand the use case - why would anything need to point to a Credential's condition profiles, other than that credential itself?

In the case above, I could see the value in having the learning opportunity indicate that it is preparationFor the Credential, and isSimilarTo the Learning Opportunity, but I do not see any useful value in pointing some external entity to a Credential's conditions. ConditionProfiles, at least as I have always conceptualized them, are integral to the Credential to which they are conditions for - it makes sense to reference their Credential, but not the Conditions themselves.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CredentialTransparencyInitiative/vocabularies/issues/176#issuecomment-260780688, or mute the thread https://github.com/notifications/unsubscribe-auth/ACzYpgEASpj0LdQ66OEvyDjMh_tTu6S3ks5q-ikKgaJpZM4Ktvoy .

[siuc-nate]

Notes from our 11/28/2016 call: If CTIDs are assigned to organizations, learning opportunities, assessments, etc., they would be one opaque format for all types of resources rather than attempting to namespace the URIs in some fashion.

Example PURL: http://purl.org/ctdl/resource/ Usage: http://purl.org/ctdl/resource/urn:ctid:12345678-1234-1234-1234-1234567890ab resolves to something like: http://www.ce-registry.com/ctid/urn:ctid:12345678-1234-1234-1234-1234567890ab It would be the job of the consuming system to determine whether the returned object is a credential, organization, assessment, learning opportunity, etc.

Action items:

• Create the PURL: http://purl.org/ctdl/resource/ that resolves to the registry equivalent of http://www.ce-registry.com/ctid/

[stuartasutton]

That is correct...and as it should be. The "opacity axiom" for URI from the horses mouth (Sir Tim Berners Lee) states:

"The only thing you can use an identifier for is to refer to an object. When you are not dereferencing, you should not look at the contents of the URI string to gain other information."

It is dangerous to have systems trying to figure out anything by parsing a URI and can lead to broken architecture. For example, ASN-D2L does not create URI that indicates which state a standards is from or to cluster standards documents from statements--all are in /resources/:

http://asn.desire2learn.com/resources/D2725060

[jeannekitchens]

The bottom line is whether to use PURLs for descriptions of credential assets. The only reason to use PURLS if if we lack confidence in the Credential Engine URIs. If there is any question of long-term sustainability PURLS have to be used or we have to be able to transfer the namespace.

We need to ensure the Credential Registry, has a provision for long-term sustainability. Need to be able to allow for the transfer to another organization that meets the criteria established by CER. In the event of such a transfer, the domain name needs to be cleanly transferable.

It is advisable that there be a contingency plan and agreement to allow the clean transfer of CER. It must be cleanly transferable.

The recommendation is that PURLS not be used.

[mparsons1953]

We will not have PURLs for CER assets. Instead we should use the following namespace: http://credreg.net/resource/ + uuid

Jeanne, Mike, Nate, and Stuart agree that http:/credreg.net is an appropriate namespace for all described assets (credentials, organizations, learning opportunities, assessments, conditions?).

[stuartasutton]

Just one small adjustment "/resources/" instead of "/resource/"; thus

http://credreg.net/resources/ + uuid

[siuc-nate]

I'm not sure that we want to mix the schema with the instances of the resources themselves (despite my indirect "agreement" a few posts up). I suppose if we use credreg.net as a sort of PURL-style redirect to a URI that actually lives in the registry, that might make be okay.

So http://credreg.net/resources/[UUID or CTID] would redirect to http://ce-registry.com/resources/[UUID or CTID] or http://credentialregistry.org/resources/[UUID or CTID]

What is the actual domain of the credential registry itself? As in, the server that you would get the JSON documents from?

Also, should we use http:// or https:// for resource URLs? The examples above do not directly address this. Both the credreg URL and the credential registry URL should use the same protocol, whichever it is.

[siuc-nate]

We have settled on using credentialengineregistry.org/resources/ce-[UUID] as the format for our URIs.

It will be prefixed with either http:// or https:// depending on our decision in #264. Refer to that issue for more info.