Open philbarker opened 1 year ago
@philbarker, I agree with your conclusion as to consequence. Both id
and type
have been there since before I joined the project. The type
property used to be typeUrl
and I dropped the "url" since I don't think it should ever be part of a property name.
Type:
I personally think type
should be rethought, redefined and renamed. While missing from the documentation property description tables , here is how is has been defined:
scd:type a rdf:Property ; rdfs:label "Type"@en-US ; rdfs:comment "Type, class or category of the competency"@en-US ; skos:note "The referenced resource is a type defining: (a) level in a hierarchical framework (e.g. \"subject\", \"strand\", \"standard\", \"benchmark\", \"indicator\", \"task\"); (2) functional class (e.g. \"condition\", \"context\", \"criteria\", \"outcome\"), or (3) a category (e.g. \"knowledge\", \"skill\", \"ability\", \"behavior\", \"habit of mind or practice\").\n\nThe preference is for the types to be defined as concepts (skos:Concept) in a machine-actionable concept scheme (skos:ConceptScheme)."@en-US ; sdo:domainIncludes scd:CompetencyDefinition; sdo:rangeIncludes sdo:URL .
The current scope note aligns the intention of the property with asn:statementLabel
and ceasn:competencyCategory
. Both ASN and CTDL-ASN used the categories as a means of refining their Statement and Competency classes. As a result, I think both type
of typeUrl
are misleading as is rdfs:comment
.
Identifier:
At least, the id
property should be changed to identifier
and should either be the URI by which the property is named/identified by it creator (e.g. asn:identifier
) or framed as an alternative identifier (e.g., asn:alternativeIdentifier
with a range of rdfs:Literal
.
I suggested "competencyType" and "competencyTypeLabel" for 5.1.10 and 5.1.11 in the spec in the new v2023.json file. Open to other suggestions like competecyCategory & competencyCategoryLabel it just might be easier to push through saying it was a typo on the standard if just adding a prefix.
I think id may be fine since it is a uri/iri of the instance of the json class, i.e. consisted with json-ld @id. (unless I'm missing a nuanced difference)
I think id may be fine since it is a uri/iri of the instance of the json class, i.e. consisted with json-ld @id. (unless I'm missing a nuanced difference)
If you mean id of the JSON object than that wouldn't be too bad, so long as you can live with the same id being used if it is translated into ttl, XML, HTML etc (in other words the id isn't unique). Better to use id
for the identifier of the thing being described rather than the description, that id can be a suffix-less URL, and you can append the suffix for different expressions. I hope that's how it will be treated anyway.
I suspect that having
scd:id
andscd:type
is going to cause a lot of pain for people using JSON-LD who (a) like to hide prefixes and (b) like to alias@id
and@type
toid
andtype
.