Re: EOCred: Identifying subtypes of credential

I don't mind how category is described or used, and I like that it is
fairly meaningless in the computer lexicon (unlike type and class, as you
pointed out).

We do have precedence with category in applicationCategory
<http://schema.org/applicationCategory>, category (as you mentioned),
applicationSubCategory <http://schema.org/applicationSubCategory>.

I think to minimize our chance of misuse, calling it credentialCategory
with a definition of:

A URL, term, initialism, or phrase denoting membership in an official set,
group, category or type of credential, for example "Secondary School
Certificate", "MCSE", "Degree".

Having it take a URL, DefinedTerm or String makes sense to me. Feel free to
edit the description to make it less arcane.

--

Note: credentialCategory is disarming to presumptuous software folk like me
who "know what type and class means" and have a tendency not to read
descriptions. That's primarily why I'm for it over the rest of the choices.

On Fri, Jan 26, 2018 at 1:54 AM, Phil Barker <phil.barker@pjjk.co.uk> wrote:

>
>
> On 25/01/18 14:29, Fritz Ray wrote:
>
> Sure. I posted my work here.
>
> https://github.com/Lomilar/schemaorg/blob/8dd7f243103c1e997e22189b56f453
> d599b74762/data/ext/pending/issue-1779.rdfa
> [...]
>
> Thanks Fritz, that helped me clarify what you're thinking. It seems
> technically correct and based on reasonable assumptions.
>
>
> I concede that this is a fairly 'puritan' approach to typing, and that it
> presumes a certain complexity of the technology used to interpret these
> objects (namely to interpret class structures inside and outside
> schema.org). It also presumes a willingness for organizations with
> particular definitions to extend schema objects with those particularities.
> If publishing schemas were as simple as publishing data, this wouldn't be a
> problem, but alas.
>
> Yes, these for me are the killer problems. Long experience shows that
> convincing organizations to publish schemas is very difficult and progress
> is slow to none existent. I think the presumption of willingness is wrong
> (the RDFSchema spec is 20 years old in April, they've had long enough to do
> it if they wanted). The problem this causes becomes worse when you consider
> that (especially in schema.org use cases) it may not be the organization
> providing the credential that wants to provide information about them. One
> reason schema.org massively increased the provision of RDF / linked data
> has been the tendency to favour approaches which make it easier to provide
> data (even when at some cost in terms of rigor or ease of consuming data).
>
>
> If this argument fails to convince, perhaps a rename to 'credentialTerm'
> to get it away from the connotations of type? I really want some property
> of Thing like "alsoCalledA" that allows one to provide a preferred name for
> the class of thing it is (commonly found as options in the description, see
> CreativeWork's description, for instance).
>
> Happy to explore naming options, but I think it is important that the term
> label does not obscure the intent of the property. Some options...
>
> cedentialTypeTerm (since we're pointing to a DefinedTerm--note, IMO
> schema's loose approach to defining Range makes putting the expected range
> into the term name problematic)
>
> credentialCategory (maybe a subtype of category
> <http://schema.org/category>)
>
> credentialClass (yeah, I know, Class not much different to Type)
>
> Personally, I am not sure I prefer any of those to credentialType, but if
> renaming is the route to a compromise solution it would be worth
> considering. One thing I might say in favour of credentialType is that it
> makes the compromise involved explicit.
>
> Would keeping the term name but changing the definition help:
> credentialType : a term describing the type of credential, for example
> "degree”, “certificate”, “badge”, or more specific term.
>
> Regards, Phil.
>
> --
>
> Phil Barker <http://people.pjjk.net/phil>. http://people.pjjk.net/phil
> PJJK Limited <https://www.pjjk.co.uk>: technology to enhance learning;
> information systems for education.
> CETIS LLP: a cooperative consultancy for innovation in education
> technology.
>
> PJJK Limited is registered in Scotland as a private limited company,
> number SC569282.
> CETIS is a co-operative limited liability partnership, registered in
> England number OC399090
>