link relations for RDF

[dret]

when working with the SemWeb/RDF community, it becomes obvious that link relations (and any other registries that manage concepts through non-URI identifiers) are a challenge for that community. even if they want to (re-)use those concepts, they cannot legally do so within RDF, because RDF requires identifiers to be URIs.
would it make sense to include something in RFC 5988bis that would allow RDF representations to use registered link relations as URIs? It would not be pretty to do that, because then on the web, registered link relations would be strings, and on the semantic web, they would be some form of equivalent URI. but maybe such a solution would be better than not doing anything, and making it impossible for RDF-based models to properly use registered link relations at all?

[darrelmiller]

I see no reason why 5988bis could not indicate that all registered link relations could be resolved to a URI such as http://www.iana.org/assignments/link-relations/{relname} or something like that. In 5988 even extension link relations are not required to actually be serialized as URIs as long as there is some process to generate a URI identifier.

[jasnell]

FWIW, this approach was attempted in RFC4287 (http://tools.ietf.org/search/rfc4287#section-4.2.7) but exceedingly few implementers would actually treat the registered short form as being equivalent to the absolute URI form. In fact, Apache Abdera is the only implementation I'm aware of that did. So the real question is: would implementers actually pay attention to this and implement it? I'm not so sure.

[dret]

i was aware of the RFC 4287 history. and i am not proposing to re-instate what was done there. on the web, link relations should be continued to use as they are. but one could say how registered link relations are identified on the semantic web, and that really was all i wanted to propose. the URI identifiers would be for RDF only.

[mnot]

"Registered Relation Types" could say something like:

Applications that wish to refer to registered relation types with a URI MAY do so by resolving them [ref to 3986] with the base URI "http://www.iana.org/assignments/relation/". Note that processors will not consider such URIs to be equivalent to their corresponding registered relation.

[dret]

i'd be more cautious than that, mark. i would be very specific about the fact that the URI version are not the same as the RFC5988 identifiers, just to make sure that the URIs do not start creeping into the web and then we have interoperability problems. all i would say is for those who for some reason have painted themselves into a corner where they need URIs, here is a prefix you might want to use. and maybe that's exactly what you're saying, and i have no specific suggestion how to improve on that. i just would try to make sure as much as possible that the "URI aliases" do not start leaking into the web.

[mnot]

Makes sense.

[timbl]

We should either use a URI properly or not at all.
Interesting that RFC4287 (http://tools.ietf.org/search/rfc4287#section-4.2.7) calls for the relationship rel=meta for example to be considered to be that identified by the URI http://www.iana.org/assignments/relation/meta -- but that is in fact alas 404.

I think it is valuable to have a namespace for all occurrences of something. The rdlib.js library tracks metadata from HTTP requests in the RDF model, and uses for example, an a namespace httph: http://www.w3.org/2007/ont/httph# for all HTTP headers:

"his vocabulary is a one deemed to contain all HTTP headers.
The rdflib.js library uses it as for relationships between an HTTP response
and the content (value) of the HTTP header in that response. The ontology
is deemed to contain one property for every HTTP header, standard or not.
The property in this ontology has a localname which is the header field converted
to lower case."

Currently, searching for a link with a relationship is a pain, I would prefer to add code which generated a direct relationship in a specific namespace. Much more the RDF way. We are happy to host the namespace on w3.org/ns and give a set of editors access. If IANA host it, will they (a) actually put something there and (b) allow the experts (like you Mark) to update it easily? Should it be a wiki even?

[jasnell]

@timbl: We can certainly try. The IANA registry currently has a csv representation of the link relation definitions. I've used that to autogenerate a JSON-LD @context of the registry. Something similar could be put in place to generate a resource in the w3.org/ns namespace giving each of those link relations a home. Then either rfc5988bis or another RFC can be written up establishing the w3.org/ns namespace. Doing so would be quite valuable, imho.

[mnot]

@timbl I'm very interested in exploring how to improve registry process -- whether that's improving IANA or doing something completely different. Going to talk to some people about this at IETF next week to get an idea of what's possible.

This is really #40 btw.

[dret]

regarding "We should either use a URI properly or not at all": RFC 5988 thankfully makes it clear that first and foremost, the link relation URIs are identifiers, and should be treated as such. all this issue is trying to track is RDF's incompatibility with RFC 5988 registered relations, and how to best deal with this without compromising how RFC 5988 is used widely today.

[elf-pavlik]

https://html.spec.whatwg.org/multipage/semantics.html#other-link-types

4.6.5.17 Other link types

Extensions to the predefined set of link types may be registered in the microformats wiki existing-rel-values page. [MFREL]

Anyone is free to edit the microformats wiki existing-rel-values page at any time to add a type.

http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions @tantek

[tantek]

And http://www.w3.org/TR/html5/links.html#other-link-types as well.

[dret]

@elf-pavlik, just for clarification: this is just HTML5 doing its usual NIH dance. the way how link relations on the web are used and defined is still specified by RFC 5988.

[elf-pavlik]

Currently, searching for a link with a relationship is a pain, I would prefer to add code which generated a direct relationship in a specific namespace. Much more the RDF way. We are happy to host the namespace on w3.org/ns and give a set of editors access. If IANA host it, will they (a) actually put something there and (b) allow the experts (like you Mark) to update it easily? Should it be a wiki even?

while microformats wiki looks already endorsed by W3C in http://www.w3.org/TR/html5/links.html#other-link-types

maybe we could work on fixing issues with link relations not having proper URIs which also provide their own description? @tantek do you see possibility of enhancing http://microformats.org/wiki/existing-rel-values to address those concerns?

[tantek]

dret said: "just for clarification: this is just HTML5 doing its usual NIH dance. the way how link relations on the web are used and defined is still specified by RFC 5988."

This is neither a clarification nor true.

HTML5 deliberately abandoned the IANA / RFC5988 ceremony bureaucracy for link registrations because it proved to be unnecessarily inefficient, and instead, chose to "just use a wiki" for link registrations, and in this case, the most complete wiki resource that already existed which was/is http://microformats.org/wiki/existing-rel-values (which itself was not created by the HTMLWG, thus the claim of NIH is false as well).

If you want further clarification and citations of public discussion of how this decision happened, please contact the HTMLWG chairs and/or contacts listed on the WG home page: http://www.w3.org/html/wg/

Elf quoted someone "Should it be a wiki even?"

It already is a wiki.

[dret]

@tantek, what you write is true about what HTML5 is doing (and i don't think i disputed that), which was my point. but link relations are used in many other places across the web (which is a much larger space than just HTML5). what happens there is entirely unaffected by what HTML5 says or does; RFC 5988 is what matters.

[tantek]

The HTMLWG (and WHATWG for that matter) have both taken the forward step of obsoleting that aspect of RFC 5988, in favor of just using a wiki page for registration, and I'd encourage any "other places across the web" that use link relations to do so as well.

As HTML is how people interact with the web for the most part, RFC 5988 no longer matters in that regard, and thus secondary uses of link relations should take the same forward step.

[mnot]

@tantek and @dret - this back and forth isn't productive. RFC5988 clearly needs to evolve, and HTML can't unilaterally do it for the whole world -- just for its sandbox (which is NOT the whole world, despite some people's aspirations).

[jasnell]

Thanks @mnot ... I was just getting ready to set an email filter to tune this particular thread out. The key question is how exactly does 5988 need to evolve. Aligning the specific syntax rules with HTML5's definition would be a good start, figuring out how best to use link relations in things like json-ld and linked data would be good, determining the future of the IANA registry would be another. I'm all for trying to see if we can come up with a more open or flexible registration process somehow.

[tantek]

mnot: "RFC5988 clearly needs to evolve, and HTML can't unilaterally do it for the whole world -- just for its sandbox"

Thanks @mnot. I agree completely with both of these. We had to break-up the political-inertia behind 5988 somehow, and forging forward first with only HTML5 made a lot of sense. In the years since that explicit switch from email/IANA -> wiki, it's been a good experience, and thus I think it now makes sense to broaden the solution adopted by HTMLWG and WHATWG, even if just one client/WG/technology at a time (whether for HTTP, JSON-LD, LDP, etc.).

@jasnell - by all means, if you come up with an improvement over and above what HTMLWG/WHATWG have successfully used for years, please make a proposal. I'm all for more such sandbox experiments to improve/minimize process.

[mnot]

Keep in mind that IANA is contractually bound to implement what the IETF tells them to do. If we tell them to run a wiki, they'll run a wiki.

[tantek]

I have no better way of putting this, but to be blunt I think there's been a growing cultural impedance mismatch between IANA/IETF and modern web (specification) development practices. Not sure an IANA run wiki would help.

I don't have any suggestions for fixing this (except by openly bringing it up to start a conversation). Just wanted to point out that this rel registry issue is just one symptom of a much larger iceberg IMO.

[mnot]

I don't disagree, but there's an awfully fine line between "modern web spec development practices" and "Not Invented Here" these days...

[elf-pavlik]

IMO usage of full URIs addresses issue of who and how runs THE registry, by simply making such construct much less needed, if at all. While I understand that many people see need for some kind of a central registry, just on this thread we can see that agreeing on it may come as major challenge.
BTW for Linked Data people also create aggregation services enabling to easily search terms across hundreds of independently hosted vocabularies, eg: http://lov.okfn.org

i'd be more cautious than that, mark. i would be very specific about the fact that the URI version are not the same as the RFC5988 identifiers, just to make sure that the URIs do not start creeping into the web and then we have interoperability problems.

Once some central registry of link relations, also provides proper prefix to create URIs for all the local identifiers. We could possibly recommend something similar to JSON-LD Flattened Form to prevent full URIs appearing where someone doesn't expect them. It should work fine with RDFa, people using Microdata may struggle a bit using multiple vocabularies and AFAIK Microformats doesn't allow use of terms from independent vocabularies but still one could use MF terms with other syntax eg: JSON-LD: Microformats given proper prefix available. Currently I see three interesting prefixes to adopt.

• http://www.iana.org/assignments/relation/
• http://microformats.org/wiki/rel- and http://microformats.org/profile/

In long run I see various benefits of more systems properly handling URIs and prefixes.

[mnot]

FWIW - I've checked with the Powers that Be (i.e., some ADs), and in principle, yes, we can use a wiki. Documenting how the wiki is to be run is the main challenge.

[dret]

On 2014-11-25, 06:00, Mark Nottingham wrote:

FWIW - I've checked with the Powers that Be (i.e., some ADs), and in
principle, yes, we can use a wiki. Documenting how the wiki is to be run
is the main challenge.

and that indeed is the crux, right? in the end, it's the process that
matters when it comes to determining which link relation values are
considered to be "well-known"/"registered", and which aren't.

whether the process results end up in an IANA-hosted registry or in a
wiki (on IANA or other sites) is mostly a question of preferences about
URI prefixes and organizations.

[mnot]

If it's in a wiki, "registered" is "somebody has bothered to edit the wiki."

The process would mostly be about dispute resolution, dealing with spammers / squatters, etc. It would probably be necessarily lightweight, otherwise the virtues of a wiki would be lost.

[elf-pavlik]

It looks that another big difference in using link-relations/predicates in RDF serializations and in HTTP Link Header relates to using them as in(re)verse. In Web Linking spec we find:

The "rev" parameter has been used in the past to indicate that the
semantics of the relationship are in the reverse direction. That is,
a link from A to B with REL="X" expresses the same relationship as a
link from B to A with REV="X". "rev" is deprecated by this
specification because it often confuses authors and readers; in most
cases, using a separate relation type is preferable.

https://tools.ietf.org/html/rfc5988#section-5.3

While many people discourage defining separate relation for in(re)verse in RDF vocabularies since it may require OWL reasoning (owl:inverseOf) when processing the data:
https://lists.w3.org/Archives/Public/public-vocabs/2015Mar/0189.html

[timbl]

On 2015-04 -04, at 16:17, ☮ elf Pavlik ☮ [email protected] wrote:

It looks that another big difference in using link-relations/predicates in RDF serializations and in HTTP Link Header relates to using them as in(re)verse. In Web Linking spec we find:

The "rev" parameter has been used in the past to indicate that the
semantics of the relationship are in the reverse direction. That is,
a link from A to B with REL="X" expresses the same relationship as a
link from B to A with REV="X". "rev" is deprecated by this
specification because it often confuses authors and readers; in most
cases, using a separate relation type is preferable.

Yes the above passage is unfortunate and in the spec "against my better judgement" as they say.

I would personally encourage people to use "rev" as well as "rel', and to invent only one predicate not two.

It is worth starting a movement to have the spec changed, or the modern style to issue another best practice spec which is a "willful violation" of the current HTML one?

https://tools.ietf.org/html/rfc5988#section-5.3

While many people discourage defining separate relation for in(re)verse in RDF vocabularies since it may require OWL reasoning (owl:inverseOf) when processing the data:
https://lists.w3.org/Archives/Public/public-vocabs/2015Mar/0189.html

—
Reply to this email directly or view it on GitHub.

[elf-pavlik]

I believe most of the people participating in this issue will also attend TPAC 2015, maybe it will give an opportunity to meet face 2 face and discuss possible improvements to current state of things?

As of today, attempts to navigate between link-relations and RDF predicates mismatch, results in proposals like for example @jasnell's http://www.w3.org/TR/activitystreams-vocabulary/ Which has tons of reverse properties defined on vocabulary level (20) and tries to introduce constructs like as:Link with as:rel

At the same time on http://microformats.org/wiki/existing-rel-values I see proposed relations with DCTERMS namespace e.g. DCTERMS.creator @tantek
Also human and machine readable mappings for example between http://microformats.org/wiki/rel-publickey and https://w3id.org/security#publicKey (owl:equivalentProperty) could help with making things more inter-operable while allowing people who implement things to work with technology of their choice.

I really wish that people responsible for current state of things will make serious effort to engage in dialog about possible solutions. Especially that many possibilities for improvement exist and most likely just require solid evaluation by everyone involved.

[elf-pavlik]

@gkellogg in w3c/csvw#297 (comment)

I can add it to th examples directory. I will also likely use it to create a cache IANA vocabulary for my Ruby RDF libraries, as users have been clamoring for this.

{
  "url": "http://www.iana.org/assignments/link-relations/link-relations-1.csv",
  "tableSchema": {
    "aboutUrl": "{name}",
    "lang": "en",
    "columns": [
      {"name": "name", "title": "Relation Name", "propertyUrl": "rdfs:label"},
      {"name": "comment", "title": "Description", "propertyUrl": "rdfs:comment"},
      {"name": "type", "title": "Reference", "propertyUrl": "rdf:type", "valueUrl": "rdf:Property"},
      {"title": "Notes", "suppressOutput": true}
    ]
  }
}

w3c/csvw@976ada9

[elf-pavlik]

w3c/Micropub#1 (comment)

In issue above @tantek and aaronpk argue that registry recommended by WHATWG and W3C in HTM5 spec - http://microformats.org/wiki/existing-rel-values also applies to HTTP Headers and using micropub and webmention there does NOT require additional registration with IANA.
In response to issue I raised that relations not registered with IANA should use full URI when used in HTTP Header. While for relations registered on microformats wiki can use short form but only when used as value of HTML rel/rev attribute.

Note that extension relation types are REQUIRED to be absolute URIs
in Link headers, and MUST be quoted if they contain a semicolon (";")
or comma (",") (as these characters are used as delimiters in the
header itself).

https://tools.ietf.org/html/rfc5988#section-5.3

I don't argue here for any particular solution, just raise issue that such unclear situation about link relations / rdf:Property blessed registry, and having different ones for HTTP, HTML (why not JSON), can have consequences in future interoperability. Here again lack of official URIs for link relations / rdf:Property(ies) defined in IANA and microformats blessed registries, prevents those, who want to stay very precise about which particular terms they use, from simply using such URIs as truly unique identifiers 😞

[mnot]

Reading over this issue, I think we're actually talking about a number of (hopefully separable) issues:

This issue is "how do I find a link for a registered relation type." I think the resolution is a modification of what I suggested way above (incorporating feedback from @dret). In "Registered Relation Types", add:

Applications that wish to refer to registered relation types with a URI [RFC3986] MAY do so by prepending them with "http://www.iana.org/assignments/relation/". Note that the resulting strings are not considered equivalent to the registered relation types by many processors, and SHOULD NOT be serialised unless the application using link relations specifically allows them.

(with possible adjustments to the prefix depending on decisions below)

Another issue is "What are the rules for getting things into and maintaining the registry?" That's #40.

Finally, there's "Where should the registry be hosted?" Provided #40 is dealt with adequately, this is mostly a question of who can meet the requirements, in terms of software, stability, resources, oversight, etc. I don't think that should have an issue number or be discussed until we figure out what those requirements are.

@tantek, I'd love to have a discussion with you about the process used for the wiki over on #40.

[elf-pavlik]

@timbl @mnot @tantek sadly I don't see any progress in #40 😟
If you all participate in W3C TPAC 2015, maybe at least all three of you could discuss this issue there IRL?

Once again, I find current situation harmful for The Internet & The Web ecosystem as a whole! Having a different link relations registry for HTML5 media type and a different for HTTP Headers and all the non HTML5 media types doesn't seem to make any sense from technical perspective, and it seems more of a very unfortunate outcome of possible drama between standards organizations / working groups (happy to stand corrected here! and 👍 / 👎 from others following this thread very welcomed)

IMO we also need stable official prefix ASAP to use with relations like: describes/descirbedBy when used in JSON-LD, Turle, RDFa and all the other RDF serializations (eg. w3c/csvw#297 (comment))... or

link relation	Activity Streams 2.0	Hydra Core
first	as:first	hydra:firstPage
previous	as:prev	hydra:previousPage
next	as:next	hydra:nextPage
last	as:last	hydra:lastPage

[asbjornu]

I agree with @elf-pavlik. The current situation is indeed harmful and even more fragmentation is being suggested as we write this, by different RDF based vocabularies defining their own semantics and names for relations that already exist in IANA. Not having a single registry for this that can support RDF, HTML5 and HTTP headers is quite terrible.

@timbl writes:

I would personally encourage people to use "rev" as well as "rel', and to invent only one predicate not two.

In an ideal world, I agree, but as per the research done while creating HTML5:

Given that rev=made was the only significant non-typo usage of the rev attribute, HTML 5 added rel=author to make up for the loss of rev=made in HTML 4, thus allowing the working group to obsolete the rev attribute altogether. Other than the un/semi/sortof-documented rev=made value, people typo the "rev" attribute more often than they intentionally use it, which suggests that the world would be better off if validators could flag it as non-conforming.

As rev is obsoleted in HTML5, and given the research that led to that decision, I think it's wise to obsolete it in all other media types too and instead pay the overhead it is to define two inverse predicates.

[niklasl]

👍 Certainly agree. Adding some simple RDFS statements about the IANA relations in one of the official representations has come up for many years. Now there might be interest enough and traction to make it happen. It would be quite simple to do so (e.g. by adding some RDFa like in http://www.w3.org/1999/xhtml/vocab#).

The "reinvention" of them in various vocabularies is understandable but fragmenting. That can be made interoperable by equivalence statements linking to the IANA "base properties".

[stain]

+1 to add RDFa or similar, for both link relations and media types. Link types and media types are used beyond HTTP headers and need stable URIs, not just "The word disclosure in that IANA Link registry you know".

For media types I have previously used http://purl.org/NET/mediatypes/ as not all media types have URIs at IANA - http://www.iana.org/assignments/media-types/text/plain is the most glaring example - but now http://mediatypes.appspot.com/ (as the purl redirect to) has stopped working. I agree with @dret that these should be hosted by IANA instead of third-parties.

It should be possible to edit link-relations.xsl and/or iana-registry.xsl to generate RDFa.

See also this RDF/XML approach by @acoburn:
samvera-deprecated/rdf-vocab@4b8457c

[niklasl]

@stain Indeed, tweaking the relevant part of link-relations.xsl to something like:

<xsl:when test="../@id = 'link-relations-1'">
  <tr typeof="owl:ObjectProperty" resource="http://www.iana.org/assignments/relation/{iana:value}">
    <td property="skos:notation"><xsl:value-of select="iana:value"/></td>
    <td property="dc:description"><xsl:apply-templates select="iana:description"/></td>
    <td rel="dc:references"><xsl:apply-templates select="iana:spec"/></td>
    <td>
      <xsl:if test="iana:note">
        <xsl:attribute name="property">skos:note</xsl:attribute>
      </xsl:if>
      <xsl:value-of select="iana:note"/>
    </td>
  </tr>
</xsl:when>

would do the trick.

[stain]

great, @niklasl - I made something along those lines - perhaps you could help me finish it? Not sure if owl:ObjectProperty is appropriate, so I went with just skos:Concept

See https://gist.github.com/stain/d4656bede203b7c3ba4e
Feel free to use. CC0 or whatever.

[stain]

Being compatible with @acoburn approach I used URIs like http://www.iana.org/assignments/relation/terms-of-service as it HTTP-redirects correctly to the XHTML, I didn't think http://www.iana.org/assignments/link-relations/link-relations.xhtml#terms-of-service would be a nice identifier.

A compromise could be http://www.iana.org/assignments/link-relations#terms-of-service which with a bit of id="relation" would scroll to the right line.

(I am not sure about the difference between /assignments/relation and /assignments/link-relations -- IANA folks?)

[mnot]

I've created #140 to capture the specific issue about registered relation types.

#40 is about the management of the registry itself.

[IS4Code]

It's been 8 years, has anything improved? At least the redirect from http://www.iana.org/assignments/relation/rel is there, but no semantic improvements to the XSL.