Missing extension of prefix table with vocabulary namespaces

[stuartasutton]

We need to get the namespace prefix table at the top of the viewer updated ASAP to include the vocabulary concept terms namespaces. I have created a google sheet that once verified as accurate can be used. Note also that it adds an additional schema namespace to handle status ("sw" for stable/unstable).

https://docs.google.com/spreadsheets/d/1UIJtldeslzCzqJDyhnAhGBVxciJFOZDmnYKBAtY5Ngk/edit

[siuc-nate]

In working on this, I noticed we do not have PURLs or prefixes for IndustryClassification, InstructionalProgramClassification, and OccupationClassification - all three of which reference external vocabularies. I'm not sure we need PURLs or prefixes for these - @stuartasutton can you confirm?

Thanks.

[stuartasutton]

No, we do not need vocabulary prefixes. The classes themselves are in the /terms/ namespace. They are there so that external vocabularies of these sorts can declare their vocabularies to be of these classes. So, this is quite intentional.

[stuartasutton]

Notice that the definitions of all three ending in "Classification" say that they are "The class of enumerations..." and not "An enumeration...".

[siuc-nate]

I added a few notes to some of the vocabulary table rows indicating places where there is an issue with the PURL.

[stuartasutton]

I don't understand "issue with the purl" of where you've added the notes.

[siuc-nate]

• The assessMethod PURL does not exist, and needs to be created
• The audLevel PURL does not exist, and was not created because the AudienceLevel vocabulary is unstable
• The purpose PURL does not exist, and was not created because the Intended Purpose vocabulary is unstable
• The deliveryType PURL exists; however, it is not clear whether it is intended to lead to the property or the class (deliveryType vs DeliveryType) - See #231

[siuc-nate]

I have corrected the issue with the deliveryType PURL

[siuc-nate]

I have created the assessMethod PURL and tested it - it is working.

[stuartasutton]

Ah, I see...(purl issues)

[siuc-nate]

I have added the table - is there anything else or can this issue be closed?

[stuartasutton]

Well, until the missing purls are all in place, the issue won't really be closed. Perhaps creating a more targeted issue on the missing purls and the rationale for them that cross-references this issue but is targeted only on the missing purls in the prefix tables...and then close this issue.

[stuartasutton]

Nate, the namespaces for vocabularies in the viewer prefix table are wrong in two ways -one your and one mine.

1. please replicate the namespaces as you see them in https://docs.google.com/spreadsheets/d/1UIJtldeslzCzqJDyhnAhGBVxciJFOZDmnYKBAtY5Ngk/edit#gid=1865936511 . You left off the /vocabs/ part of the URI. That explains your note that the one of the PURLs was "ambiguous". There is nothing ambiguous since the /vocabs/ in the PURL is totally different from the properties/classes.

2. In the document, I left off the trailing slash "/" for use with these as partial redirects. Partials have to end in either a hash ("#") or a slash ("/").

http://purl.org/ctdl/vocabs/actionStat/ http://purl.org/ctdl/vocabs/agentSector/ http://purl.org/ctdl/vocabs/serviceType/ http://purl.org/ctdl/vocabs/assessMethod/ http://purl.org/ctdl/vocabs/assessUse/ http://purl.org/ctdl/vocabs/audience/ http://purl.org/ctdl/vocabs/audLevel/ http://purl.org/ctdl/vocabs/claimType/ http://purl.org/ctdl/vocabs/costType/ http://purl.org/ctdl/vocabs/statusType/ http://purl.org/ctdl/vocabs/creditUnit/ http://purl.org/ctdl/vocabs/deliveryType/ http://purl.org/ctdl/vocabs/inputType/ http://purl.org/ctdl/vocabs/purpose/ http://purl.org/ctdl/vocabs/learnMethod/ http://purl.org/ctdl/vocabs/orgType/ http://purl.org/ctdl/vocabs/residency/ http://purl.org/ctdl/vocabs/score/

[stuartasutton]

@siuc-nate, @mparsons1953, & @jkitchensSIUC:

What I am saying here about the PURLs for vocabulary concepts comports with the planning doc: https://docs.google.com/document/d/1xqK7XSQsEK-CB3_6g5CG0z5Q0PKAPI851fazVwq68sQ/edit#heading=h.4d34og8 (although the table at the bottom remains pretty mess up). Unfortunately, what was entered into the PURL service does not comport with the planning doc. The vocabulary concepts PURLS (e.g., http://purl.org/ctdl/vocabs/actionStat/ & http://purl.org/ctdl/vocabs/agentSector/) should be in the /ctdl/vocabs/ purlspace and not in /ctdl/ purlspace) and should have PURLS like this:

/ctdl/vocabs/actionStat/ (partial) /ctdl/vocabs/agentSector/ (partial)

BUT, we've all nodded our heads that we are on the same page when we are obviously not on the same page. Before any additional PURLs are entered, let's do a skype session sharing screen and actually do enough of this live that we are confident we actually are on the same page. BUT right now, we need the viewer prefix table corrected.

This is not an irredeemable PURL service error since the purls like this "/ctdl/actionStatus" (302) can be redirected to "/ctdl/vocabs/actionStatus/" (partial).

[siuc-nate]

When we created those PURLs, Jeanne and I were at the same computer (and I believe Mike was behind us for at least part of it) working on it - I find it very strange that none of us caught the missing /vocabs namespace within the PURLs themselves. I wonder if, somehow, we were working from a different document or source?

Anyway, when I was setting up the tables yesterday, I left the /vocabs out in order to match the PURLs we actually have - but I see what you're saying, and will make the corrections. It's just weird to me that none of us noticed when we were entering them.

[siuc-nate]

One question - since we changed our DeliveryType vocabulary to Delivery, do we want the purl for that to now be http://purl.org/ctdl/vocabs/delivery ?

[siuc-nate]

Actually, one more question - there seems to be a mismatch with the trailing slash (or lack thereof) between the PURLs and the URLs to which they lead. Notably there is a trailing slash on the PURLs but not on the target URLs. This would seem to only allow a situation in which the target URL has a trailing slash as well, otherwise http://purl.org/ctdl/vocabs/costType/tuition will direct to http://credreg.net/ctdl/vocabs/CostTypetuition

Would it not make more sense to leave the trailing slash off of the PURL, thus enabling: http://purl.org/ctdl/vocabs/costType/tuition http://purl.org/ctdl/vocabs/costType#tuition to direct to http://credreg.net/ctdl/vocabs/CostType/tuition http://credreg.net/ctdl/vocabs/CostType#tuition respectively? (The viewer is not currently setup to handle the second form with the #, but, should we ever want to adapt it to do so, the PURL wouldn't be an issue in this case.)

Alternatively, the target URL should have a trailing slash if the PURL has a trailing slash, to ensure http://purl.org/ctdl/vocabs/costType/tuition goes to http://credreg.net/ctdl/vocabs/CostType/tuition

Am I way off base here, Stuart?

[siuc-nate]

One more thing - The prefix "sw" is in the table for the status mechanism, but the actual prefix we're using is vs. Should "sw" not instead be "vs" (or should we change vs to sw in the spreadsheets and viewer)?

[stuartasutton]

Nate, I don't think we need be concerned about whether the URLs where these PURLS resolve have training slash/hash.

They are critical for the partial purls otherwise when the partial is complete, you get something like the following with an incorrect http://purl.org/ctdl/term without trailing slash:

http://purl.org/ctdl/termDigitalBadge

instead of:

http://purl.org/ctdl/term/DigitalBadge OR http://purl.org/ctdl/term#DigitalBadge

On your other comment, I think http://purl.org/ctdl/vocabs/delivery is OK.

[stuartasutton]

Doesn't matter to me...sw is a bit closer, but it doesn't matter. which ever is easiest to fix :-)

On Wed, Nov 23, 2016 at 9:53 AM, siuc-nate notifications@github.com wrote:

One more thing - The prefix "sw" is in the table for the status mechanism, but the actual prefix we're using is vs. Should "sw" not instead be "vs" (or should we change vs to sw in the spreadsheets and viewer)?

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

[siuc-nate]

I can see where that makes sense for concatenation to the end of a PURL, but without a trailing slash on the target URL, the reverse situation applies: http://purl.org/ctdl/term/DigitalBadge would resolve to http://credreg.net/ctdl/termDigitalBadge

[stuartasutton]

Nate, didn't read throughly. No you are not way off. I see what you are saying, but it is not good practice to leave off the trailing slash or hash from namespace declaration. Given behavior, we have to pick and use hash or slash. DCMI consistently uses slash given the comparative behavior.

[siuc-nate]

I'm updating the PURLs now, using trailing slashes on both the PURL and the target URL. While we're at it, do we want to use something different for "External Input" (currently using /ctdl/inputType/ as the PURL) since there is no "type" on the name of this one? Perhaps /ctdl/externalInput/ ?

[stuartasutton]

Sounds like a reasonable change.

[stuartasutton]

I see...

On Wed, Nov 23, 2016 at 9:59 AM, siuc-nate notifications@github.com wrote:

I can see where that makes sense for automated concatenation to the end of a PURL, but without a trailing slash on the target URL, the reverse situation applies: http://purl.org/ctdl/term/DigitalBadge resolves to http://credreg.net/ctdl/termDigitalBadge

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

[siuc-nate]

Similarly to the above change, I just realized we removed "type" from "CredentialStatusType", leaving us with "statusType" pointing to "CredentialStatus".

Currently "actionStat" points to "ActionStatus" Should "credentialStat" (or maybe "credStat") (rather than "statusType") point to "CredentialStatus"?

[stuartasutton]

Also, while this need not be done right now, the erroneous concept scheme PURLs could be mapped to their new companion PURLs; e.g.,

/ctdl/actionstat (302)==target==>/ctdl/vocabs/actionStat/ (partial) etc.

Couldn't it?

Then, if someone typed in http://purl.org/ctdl/actionStat they'd be redirected to http://purl.org/ctdl/vocabs/actionStat/ ... wouldn't they? DCMI does a variation of this.

[siuc-nate]

Yes, I will remap the PURLs once the new ones are all in place and the table is updated to use them.

[stuartasutton]

Nate, credStatus would work instead of statusType.

[siuc-nate]

I had forgotten to mention it last week, but I created a PURL of "credentialStat". I just noticed the table has the right URL but the wrong prefix - this will be taken care of with some other updates I will make this morning.

[stuartasutton]

Yes, I think I have it wrong also in the Namespace Policy document.

On Mon, Nov 28, 2016 at 8:51 AM, siuc-nate notifications@github.com wrote:

I had forgotten to mention it last week, but I created a PURL of "credentialStat". I just noticed the table has the right URL but the wrong prefix - this will be taken care of with some other updates I will make this morning.

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

[siuc-nate]

I have remapped the old PURLs to point at the new PURLs, and added a missing /ctdl/vocabs/learnMethod/ PURL (with mapping from /ctdl/learnMethod).

Is there anything else, or can this be closed?