Skip to content
This repository has been archived by the owner on Jun 18, 2024. It is now read-only.

describedBy and describedByType should become its own element and re-used at other places. #382

Open
rrmishra opened this issue Oct 22, 2014 · 5 comments

Comments

@rrmishra
Copy link

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"
}

@philipashlock
Copy link
Contributor

I think you're getting at the alternative proposal described at #332 (comment) - want to weigh in there if you think the alternative is better?

@rrmishra
Copy link
Author

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.

@philipashlock
Copy link
Contributor

@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)

Something like:

{
  "urn:iana:link-relations:describedby": {
    "@id": "http://www.example.com/file.json", 
    "type": "application/schema+json"
  }
}

@philipashlock
Copy link
Contributor

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.

@gkellogg
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants