There need to be an http-based mechanism to point to representations conforming to other profiles [ID30] (5.30)

w3c / dxwg

Data Catalog Vocabulary (DCAT)

https://w3c.github.io/dxwg/dcat/

Other

153 stars 47 forks source link

There need to be an http-based mechanism to point to representations conforming to other profiles [ID30] (5.30) #266

Closed nicholascar closed 3 years ago

nicholascar commented 6 years ago

Original wording: "Return http link headers using the following relationship types... [ID30] (5.30)"

Entered from Google Doc

derivedfrom: The URL of the source document, containing the ISO 19139 records.
profile: The URI of the metadata schema used in the returned document.
self: The URL of the document returned by the API.
alternate: The URL of the current document, encoded in an alternative serialization.

nicholascar commented 6 years ago

Lars' rewording suggestion: There needs to be a way to encode the necessary relations using an http link header

larsgsvensson commented 6 years ago

This feels more like a solution than a requirement. A req could be: "There need to be an http-based mechanism to point to representations conforming to other profiles". Using Link-headers could be a way of implementing that.

nicholascar commented 6 years ago

Changed as per Lar's suggesting with the original wording indicated in the description

aisaac commented 6 years ago

I think we should still (as part of the requirement derived from 5.30) list the "necessary relations": URL of the source document, etc (so, keeping the feature but removing the http link header that was suggested as solution)

aisaac commented 5 years ago

Just a note to clarify that my emphasis on the fact that there should be a focus on possible relations comes from my reading of the Google doc of our discussions

nicholascar commented 5 years ago

De-tagging as profile-negotiation as dealt with by its point of view

andrea-perego commented 3 years ago

@aisaac , @larsgsvensson , @nicholascar , @rob-metalinkage ,

Based on the discussion, it seems that this issue is about ConnegP and/or PROF, and that it has been addressed in both.

Should we close it?

nicholascar commented 3 years ago

Yes, I think this is dealt with in ConnegP and the Alternate Representations data model ref in ConnegP. It's actually outside PROF's concerns as PROF only IDs and described the profiles.