- From: Tomasz Pluskiewicz via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 May 2021 18:00:30 +0000
- To: public-hydra-logs@w3.org
Great! I think profile content negotiation is exactly what I'm looking for. Rather than using the `return=minimal` preference, which is intentionally vague, we could define a well-known identifier for a "canonical representation", which I would then implement as one which excludes any inferred, generated, or external (imported) knowledge about a resource. ```http Accept-Profile: <http://www.w3.org/ns/hydra/profile#Canonical> ``` As a more generalised feature, individual API-defined profiles could simply be SHACL Shapes, so that given multiple shapes which can describe a resource, they could be chosen by the client to request a specific shape of said resource. ```turtle # This shape has Person with given name + family name <http://example.com/shape/PersonA> dash:applicableToClass schema:Person ; sh:property [ sh:path schema:givenName ] , [ sh:path schema:familyName ] . # This shape has Person with full name only <http://example.com/shape/PersonB> dash:applicableToClass schema:Person ; sh:property [ sh:path schema:name ] . ``` ```http GET /person/John Accept-Profile: <http://example.com/shape/PersonB> ``` We even discussed that the profile-shape could be an external resource which the server could dereference and dynamically create a query based on the `sh:path` values -- GitHub Notification of comment by tpluscode Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/234#issuecomment-839983299 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 May 2021 18:00:33 UTC