- From: Phil Barker <phil.barker@pjjk.co.uk>
- Date: Thu, 18 Jan 2018 10:16:45 +0000
- To: Alex Jackl <alex@bardicsystems.com>, Stuart Sutton <stuartasutton@gmail.com>
- Cc: public-eocred-schema@w3.org
- Message-ID: <249773f3-8490-0489-6088-99882c6f3304@pjjk.co.uk>
Hi Alex, I'm not quite sure which example you're referring to, but in
scheme.org every type in the hierarchy inherits the url,
<http://schema.org/url> sameAs <http://schema.org/sameAs>, and
identifier <http://schema.org/identifier> properties from Thing which is
at the top of the class hierarchy. So if the credentialType is provided
as a TermDefinition, then identifiers for the term being defined could
be provided. Which you use, I think, would depend on what type of
identifier you were providing, whether it was for human or machine use,
and, in the case of machine identifiers, what you thought the receiving
system would understand. There is also the @id mechanism in JSON and
equivalents in microdata and RDFa.
Something like this would be valid (but perhaps overkill):
{
"@type": "EducationalOccupationalCredential",
"@id" : "http://id.example.org/badges/#1", // URI for semantic web apps
"url" : "http://badges.example.org/Badge1", // url for humans
"name" : "example badge",
"credentialType": {
"@type" : "TermDefinition",
"@id" : "http://purl.org/ctdl/terms/Badge"
"name" : "Badge",
"url" : "http://credreg.net/ctdl/terms/Badge#Badge",
"identifier" : "http://purl.org/ctdl/terms/Badge",
"inDefinedTermSet" : "http://credreg.net/ctdl/terms/"
}
}
[aside: we didn't have a use case for providing identifiers for
anything; maybe we should]
Phil
On 17/01/18 17:24, Alex Jackl wrote:
> Not to ask a stupid question but, Stuart, in the example you provided
> I don't see any URI or place to put a unique identifier in. Can you
> point to how that would be handled?
>
> I probably just missed something!
>
> Alexander Jackl
> CEO & President, Bardic Systems, Inc.
> alex@bardicsystems.com <mailto:alex@bardicsystems.com>
> M: 508.395.2836
> O: 401.384.0566
> F: 617.812.6020
> http://bardicsystems.com
>
> On Wed, Jan 17, 2018 at 9:04 AM, Stuart Sutton
> <stuartasutton@gmail.com <mailto:stuartasutton@gmail.com>> wrote:
>
> Phil, I agree that a credentialType property is needed. I think
> that having the range include both Text _and_ URL to allow
> identification by URI where available and text where not is
> appropriate. You are right that CTDL defines subclasses of it's
> Credential class <http://purl.org/ctdl/terms/Credential> and that
> no single enumeration will handle the breadth of the range (and
> internationalization issues); but, where such enumeration(s)
> exist, my sense is that they should be used. The CTDL defines a
> credentialType <http://purl.org/ctdl/terms/credentialType>
> property that is intended to be used wherever reference to a
> member of the Credential class is needed. It's range now
> enumerates the CTDL subclasses; but should likely reference more
> inclusively the Credential class.
>
> As for use of TermDefinition to identify/define members of such
> enumerations, I hope that it gets approved in a timely manner and
> that we are not forced to even contemplate use of AlignmentObject
> (ugh...don't get me started).
>
> Stuart
>
> On Wed, Jan 17, 2018 at 3:20 AM, Phil Barker
> <phil.barker@pjjk.co.uk <mailto:phil.barker@pjjk.co.uk>> wrote:
>
> Hello again, moving on to the next requirement for describing
> Educational and Occupational Credentials in schema.org
> <http://schema.org>: I suggest we look at how to identify the
> subtypes of these credentials.
>
> The use case for this
> <https://www.w3.org/community/eocred-schema/wiki/Use_Cases#Identify_subtypes_of_credential>
> gives examples of "degree" "certificate" "badge". I know there
> are about 20 others from the Credential Engines' CTDL
> <http://credreg.net/ctdl/handbook#creds>. Most countries will
> have their own types of EO Credential, for example in Scotland
> we have National Qualifications, HNDs, HNCs, SVQs, IVAs,
> PDAs, DipHEs, CertHEs and many more. Other countries will be
> similar. Furthermore, the types of qualification on offer
> changes over time.
>
> In short, the number of types is we need to consider is vast
> and varied. So, while CTDL has subclasses of its Credential
> class for each of its distinct types, that is not a practical
> solution for wider use. Even if we could reduce the number and
> variety of types, I think it would add too many subclasses to
> the schema.org <http://schema.org> hierarchy, given that most
> of the subtypes would have no unique properties.
>
> The alternative is for EducationalOccupationalCredential to
> have a property which records the type of credential. With a
> nod to Richard's point that much of what we do is applicable
> to generic credentials, I propose we call this credentialType.
>
> The basic range for credentialType would be text, and I think
> we should explicitly allow this. We could stop here.
>
> In an ideal world there would be controlled vocabulary for
> naming the credentialTypes. However, I a single controlled
> vocabulary of all the precise types is not feasible, and I
> think that producing a vocabulary that classifies these types
> into categories like "certificate" would be very difficult and
> the results would be very imprecise. We should, however try to
> facilitate the use of local controlled vocabularies. This is
> where we reach the edge of what currently possible in
> schema.org <http://schema.org>.
>
> Options for facilitating the use of local controlled
> vocabularies of credential type:
>
> 1, allow a URL to link to a controlled value / external
> enumeration.
>
> 2, allow alignmentObjects to provide information about the
> credentialType as if credential types were educational frameworks
>
> 3, use the developing schema.org <http://schema.org> type that
> is currently called CategoryCode
> <http://pending.schema.org/CategoryCode>, but which is
> proposed to be changed to TermDefinition
> <https://github.com/schemaorg/schemaorg/issues/1775>
>
> In my view: 1 is too vague (who knows what will be at the end
> of the URL), 2 stretches the alignmentObject somewhat, and 3
> is the best option for the long run. An example using option 3
> would look something like:
>
> {
> "@type": "EducationalOccupationalCredential",
> "name" : "HNC Facilities Management",
> "credentialType": {
> "@type" : "TermDefinition",
> "name" : "Higher National Certificate",
> "termCode" : "HNC",
> "inDefinedTermSet" : "SQA Qualifications" //should be a
> URL or DefinedTermSet object
> }
> }
>
> What do you think? Too complicated, maybe? Am I overthinking
> the problem? Are there enough well-constructed sets of terms
> describing credential types for it to be worth trying to
> accommodate anything other than text values?
>
> 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
>
>
>
>
> --
> Stuart A. Sutton, Metadata Consultant
> Associate Professor Emeritus, University of Washington
> Information School
> Email: stuartasutton@gmail.com <mailto:stuartasutton@gmail.com>
> Skype: sasutton
>
>
>
--
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
Received on Thursday, 18 January 2018 10:17:11 UTC