-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of anchor= for linking back from metadata resources #37
Comments
No. I believe (The reverse relationship, from resource to metadata resource, gets |
Related: #33 (comment) I think these two constructs should have identical semantics:
RFC5988 asserts that
Lexically, it appear that As a design principle, I prefer to avoid making programmers search for information across multiple expressions (e.g. |
Web Linking, RFC 5988, has been obsoleted by Web Linking, RFC 8288, which deprecated
Actually, it is stated at IANA Link Relations, in the Notes for
The 'describes' Link Relation Type, RFC 6892, says much the same, in several places, including --
The significant oddness I see here is that |
Great feedback @TallTed. Seems we're right to stick with |
"using I also note that there is no I think the following covers my thinking...
|
@TallTed - thanks for making this all explicit. This kinda illustrates my point about the cost of mandating the inclusion of inverse properties. If I use rdflib's generic HTTP-header-to-RDF translator, I get the assertions you suggest we include in the bodies of <R.meta> iana-link-relations:describes <R> .
<R> iana-link-relations:describedby <R.meta> . # or powder:describedby It's a mild pain in the butt that every generic tool (e.g. a linter which reports who can edit In general, I'm all for respecting deprecation, but I think that deprecating |
While rev+anchor can be treated as semantically identical to rel+href, I'm not sure if it is simpler in the end. Implementations may of course handle them as identical. Additional considerations: rel requires two relation types whereas rev requires one relation type, however it introduces two additional attributes (rev, anchor) into the implementation. It may be preferable to encourage having self-describing resources. If so, rel+href would be preferable. |
I propose to include the following criteria for clients for discovering these resources (adapted from https://www.w3.org/TR/ldn/#discovery ):
These may be carried out in either order, but if the first fails to result in discovering the metadata resource or the resource the second MUST be tried. |
If we want to make RDF statements matching link headers we should use full URIs, IANA registered link relations don't have official maping to URIs mnot/I-D#140 (also mentioned in #38 ) |
There is https://www.w3.org/ns/iana/link-relations/relation . The relations are not tied to LDP-centric resource and Solid is not enforcing LDP's classification, so I'd suggest to define behaviour without mentioning LDP. See for example the proposed client behaviour in #37 (comment) and more broadly in #32 (comment) . By the way, what's "full URI"? Do you mean "absolute URI"? |
I meant just URI, not a registered link relation
Does some normative reference exist or solid spec would need to establish usage of that prefix for mapping IANA registered link relations to URIs in solid ecosystem? |
There is no normative reference as far as I know - don't quote me ;) [Tim created it and maintains it. I use it as is.] It is only necessary for RDF bearing documents ie. not necessary in Link header since the IANA term can be used as is at the very least. Solid specs could say that the rel URI is equivalent to the IANA term but I think that can be problematic. We should not do this! Non-registered IANA terms have local scope. So, at the moment, because eg. "acl" is not registered, my use of rel=acl and your use of rel=acl are not necessarily the same - but yes, we could look the other way and in good faith say that they are - Solid spec can make some effort to declare the definition at least (even if not part of IANA). And, so, implementations prefixing a non-URI and non-IANA registered term (like "acl") with |
I don't think we want the body of the document to include references to the metadata. Picking on e.g. ACLs:
Proposal: The response to a HEAD or GET on a LDPR R includes link headers for the different kinds of metadata: ACLs, Shape, Config, Server-managed. Specifically, there is no mention of R's body. |
@ericprud Nod. Ack. Etc. Background: IIRC, the intention started out of the possibility to have the relationships available from the RDF body because the client may not necessarily have the possibility - whether they should be able to or not may be orthogonal - to update the HTTP header information - the current design doesn't permit that eg. no LINK method or some other way to influence the headers. So, RDF body was the next possibility. The points you raise are well grounded so it make sense to not bother with discovery through RDF body, especially for something like ACL and synchronisation challenges. If we just want to link Web resources, discovery of resource metadata through Link header will suffice. One thing that the alternate RDF body approach provided is to use the relations on URIs with fragments but perhaps that's an edge case any way? I retract the proposal on discovery through RDF body. Link header should be the only required way for discovery. Aside: we can look into the possibilities through LINK or whatever separately (and whether it is sensible) |
Should anchor= be used rather than rel= when linking back to the associated resource from the metadata resource? (see RFC 5988)
The text was updated successfully, but these errors were encountered: