You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 18, 2024. It is now read-only.
Thank you @philipashlock for pointing me to #332 (comment). I agree with the comment.
My question is slightly different and very specific to describedBy and describedByType fields. Since these fields are used in other parts of the schema and they always go together, we should create a new json type that encapsulates "describedBy" and "describedByType" fields and use this new json type where it is needed.
@philarcher1 @lanthaler@gkellogg Do any of you have suggestions on representing the describedby link relation in the body of JSON while also including the associated Content-Type?
I think we'd be using this just like wdrs:describedby in ADMS, but we'd also want to include the content type as is usually done with type in a HTTP Link header.
The JSON-LD spec only covers this in the context of HTTP Link headers
I do see a JSON-LD example in the Hydra spec, but it doesn't include the content type. Would you just add type as another property? (Not to be confused with @type of course)
For the current v1.1 update we've stuck with the separate fields describedBy and describedByType but we'll leave this issue open to see if we can get feedback on existing or better ways of doing this.
I seems you want to describe provenance of the document using describedby and describedbytype; have you considered the PROV Ontology? The type of the retrieved resource might be captured using a property from the HTTP vocabulary.
describedBy and describedByType always go together. Keeping them independent causes confusion and is NOT reusable.
Suggestion:
describedBy
{
url: "www.xyz.gov/data.xml"
mediaType: "text/xml"
}
The text was updated successfully, but these errors were encountered: