URL ID for `image` typo?
Closed this issue · 9 comments
The current context file contains (note the capital I in #Image):
"image": {
"@id": "https://purl.imsglobal.org/spec/vc/ob/vocab.html#Image",
"@type": "@id"
},However, that points to the object type definition (https://purl.imsglobal.org/spec/vc/ob/vocab.html#Image) and not the property definition (https://purl.imsglobal.org/spec/vc/ob/vocab.html#image).
Small but important difference.
Thanks!
🎩
I agree with @BigBlueHat that the general convention is UpperCamelCase for class/entity types and lowerCamelCase for property names, as this is.
@BigBlueHat which version of the context are you looking at? Current version (https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.2.json) defines image as:
"image": {
"@id": "https://purl.imsglobal.org/spec/vc/ob/vocab.html#Image",
"@type": "@id"
}@xaviaracil yes that was the version of the context he was looking at. The issue is that the IRI for the type Image and the property image are the same -> "https://purl.imsglobal.org/spec/vc/ob/vocab.html#Image". Typically, image would point to an IRI like "https://purl.imsglobal.org/spec/vc/ob/vocab.html#image" instead, differentiating the definition for the class and the property.
@ottonomy got it. I've created a new branch. My main doubt is in the image entity of the top level:
"image": {
"@id": "https://purl.imsglobal.org/spec/vc/ob/vocab.html#image",
"@type": "@id"
}Source:
openbadges-specification/ob_v3p0/context-3.0.3.json
Lines 416 to 419 in 393cca2
I've set it to ...#image, but I wonder if this entity is necessary, as every entity with an image property has the image entity in their inner context.
Does the top level property in the context enable a top level image property to be present in the VC?
I see this snippet from the above link:
"image": {
"@id": "https://purl.imsglobal.org/spec/vc/ob/vocab.html#image-1",
"@type": "@id"
},
That seems incorrect.
And:
"image": {
"@id": "https://purl.imsglobal.org/spec/vc/ob/vocab.html#image-3",
"@type": "@id"
},
Seems like some bug crept in.
@ottonomy I don't see any image property in the top level in OB's datamodel. Should we remove this definition?
Regarding the rare identifiers, they're pointing out to the description of the attribute for the given entity. That's why we have several definitions for image, with differents html ids.
they're pointing out to the description of the attribute for the given entity. That's why we have several definitions for image, with differents html ids.
I don't like the modeling of issuer.image to be a separate vocabulary concept from Achievement.image etc. Ideally we just use https://schema.org/image for these things, but 1EdTech may have its own reasons for preferring its vocabulary for all terms, it can work. A generic concept for an image #image would be better I think than having different IRIs for the term image when it appears in different places in the context. I guess that's just a stylistic preference, but it seems simpler.
I don't see any image property in the top level in OB's datamodel. Should we remove this definition?
This is one of those cases where some VC sub-communities have used some top-level metadata in the VC for display in various communities. I am perfectly fine myself with removing image from top-level display. It would be useful to approach wallet implementers who participated in the JFF Plugfests to see how they have implemented image display to see if they are targeting credentialSubject.achievement.image properly.
I agree with Nate re: using https://schema.org/image. The advantage is that it increases interoperability with other linked data models outside of 1EdTech's.
For the plugfests, we listed badge image in the requirements but we should have required achievement.image which is what was intended.
I don't think we need an image at the top level. There is enough flexibility to tailor the acheivement.image to the individual credential if implementers choose to do so. By keeping it to just achievement.image vs adding a top level image, wallets and other displayer don't need to make a decision about which one to display. This has already become an issue with name and achievement.name.