Re: [dxwg] There needs to be metadata about the views provided by profiles (“named collections of properties”) that can included in a http header [ID5] (5.5)

There was a longer discussion between @azaroth42 and @nicholascar in the google doc so I copy that here for completeness

Rob S:
-1, unnecessary complication and introduces non-uniqueness challenges. Short tokens are good for humans, but humans are not the actors for content negotiation. Each token would need to be publisher specific to avoid collisions, requiring additional time and architecture for no obvious gain.

Unnecessary for machine yes but the scope of this profile neg includes humans!

Use Cases like #239 are specifically in scope so Requirements like this one follow from that.

Rob S:
Yes, and I'm questioning that scope :) What's the use case in which a token is discoverable by a human who then types it into the address bar of a browser in a particular place in order to receive content designed for machine interpretation?

Exactly as per UC 239 examples although the profile they receive may not be entirely machine-readable (e.g. an HTML web page). We have people already using the Alternates View / Linked Data Platform approach, e.g. and I've just shown that this is completely compatible with the proposed Accept-Profile and Profile HTTP conneg (see my recent emails about demos with

So this Requirement is to ensure that IF a token used THEN it must be compatible with the HTTP connect methods.

Currently my demo demo may be missing some bits to satisfy this Requirement but perhaps not: the RDF format of an Alternates View allows for graph traversal from tokens to URIs. But it was made pre-this requirement and could do with alignment with new terminology ("profile" rather than "view").

GitHub Notification of comment by larsgsvensson
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 17 October 2018 09:47:31 UTC