link relations for RDF about i-d HOT 53 CLOSED

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.

from i-d.

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.

from i-d.

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.

from i-d.

"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.

from i-d.

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.

from i-d.

Makes sense.

from i-d.

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?

from i-d.

@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.

from i-d.

@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.

from i-d.

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.

from i-d.

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

from i-d.

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

from i-d.

@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.

from i-d.

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?

from i-d.

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.

from i-d.

@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.

from i-d.

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.

from i-d.

@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).

from i-d.

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.

from i-d.

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.

from i-d.

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.

from i-d.

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.

from i-d.

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

from i-d.

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.

from i-d.

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.

from i-d.

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.

from i-d.

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.

from i-d.

hello mark.

On 2014-11-25, 09:27, Mark Nottingham wrote:

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

sure, but it seems that some process or rules how to exactly do that
probably are necessary.
http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
does have some rules in there as well, and maybe those are good enough.
and in the end, they are not that different from what RFC 5988 is doing;
just a bit more lightweight.

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.

yes, exactly. but i guess i still fail to see why a wiki would be such a
qualitative difference; it's just a different publishing method. but if
it makes people happier to see one (governed by a lightweight set of
rules) instead of an IANA-style registry, then we should have one.

from i-d.

Hi everyone, I wonder if we can add checklist with some clear ✅ ACTION points to move forward here?

@tantek & @msporny do you see any possible issues with how HTML5 and RDFa1.1 define rel ?

• http://www.w3.org/TR/html5/document-metadata.html#attr-link-rel
• http://www.w3.org/TR/rdfa-syntax/#A-rel

from i-d.

@mnot @tantek while neither IANA and microformats do NOT provide stable URI for all the terms in open controlled vocabularies, which they manage. Would you see problem if someone else provided such stable URIs, for example via https://w3id.org/ ?

• https://w3id.org/iana/type
• https://w3id.org/microformats/h-entry

(or possibly using # pattern for such nice and small vocabularies)

• https://w3id.org/iana#type
• https://w3id.org/microformats#h-entry

If one day you decide to take responsibility for hosting resources returned when dereferencing those URIs, it would just take changing redirects on w3id.org

@msporny @kidehen @prototypo do you see such approach as appropriate and along intention behind w3id.org?

from i-d.

@elf-pavlik - yes, that approach is appropriate wrt. w3id.org. If IANA / IETF wants to add themselves to be a co-maintainer of the w3id.org website, it would be welcomed w/ open arms. The same invitation has been extended to W3C, but they'd like to publish terminology such as this in W3C-space. I expect that IANA / IETF will most likely want to do the same.

For schema.org, when they weren't publishing a reasonable JSON-LD context, the JSON-LD community took it upon itself to publish something via w3id.org and implementers just linked to the w3id.org context. This may or may not have pushed the schema.org folks to publish something themselves lest w3id.org ended up becoming the main location that developers would use to reference the JSON-LD schema.org context. So, w3id.org has been used to move these sorts of discussions forward before.

I have no horse in this race, just providing info for the rest in this thread that need to make the decision.

from i-d.

+1

Regards,

Dave

http://about.me/david_wood

On Feb 23, 2015, at 08:52, Manu Sporny [email protected] wrote:

@elf-pavlik https://github.com/elf-pavlik - yes, that approach is appropriate wrt. w3id.org. If IANA / IETF wants to add themselves to be a co-maintainer of the w3id.org website, it would be welcomed w/ open arms. The same invitation has been extended to W3C, but they'd like to publish terminology such as this in W3C-space. I expect that IANA / IETF will most likely want to do the same.

For schema.org, when they weren't publishing a reasonable JSON-LD context, the JSON-LD community took it upon itself to publish something via w3id.org and implementers just linked to the w3id.org context. This may or may not have pushed the schema.org folks to publish something themselves lest w3id.org ended up becoming the main location that developers would use to reference the JSON-LD schema.org context. So, w3id.org has been used to move these sorts of discussions forward before.

I have no horse in this race, just providing info for the rest in this thread that need to make the decision.

—
Reply to this email directly or view it on GitHub #39 (comment).

from i-d.

just one word of caution: experience shows that when you create specs that say "you can refer to this concept by identifier a or b", the minority of implementations handle this correctly (see @jasnell's comment #39 (comment) and similar implementation experience from activity streams which also defined synonyms that weren't supported well by implementations). implementations mostly prefer a or b and use that preference consistently, and then stop being interoperable with those implementations that make the opposite choice.
so yes, there should be a way how data models that can only handle URI identifiers are given the opportunity to identify natively non-URI values from IANA registries. in an ideal world, this could even be approached in a way that it is not done on a per-registry basis, but consistently across (some of) them.

from i-d.

On 2/23/15 8:52 AM, Manu Sporny wrote:

@elf-pavlik https://github.com/elf-pavlik - yes, that approach is
appropriate wrt. w3id.org. If IANA / IETF wants to add themselves to
be a co-maintainer of the w3id.org website, it would be welcomed w/
open arms. The same invitation has been extended to W3C, but they'd
like to publish terminology such as this in W3C-space. I expect that
IANA / IETF will most likely want to do the same.

For schema.org, when they weren't publishing a reasonable JSON-LD
context, the JSON-LD community took it upon itself to publish
something via w3id.org and implementers just linked to the w3id.org
context. This may or may not have pushed the schema.org folks to
publish something themselves lest w3id.org ended up becoming the main
location that developers would use to reference the JSON-LD schema.org
context. So, w3id.org has been used to move these sorts of discussions
forward before.

I have no horse in this race, just providing info for the rest in this
thread that need to make the decision.

I only have one horse in this race, and its all about making names
interpretable using Linked Open Data patterns. That's it.

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

from i-d.

Elf, this is not a reasonable assumption nor framing: "while neither IANA and microformats do NOT provide stable URI for all the terms in open controlled vocabularies, which they manage" thus I interpret the rest of your proposal as unnecessary.

How are you measuring such "stability" so as is to assert it (w3id) or lack thereof?

From my experience, both IANA and microformats appear have fairly good track records of "stable URI[s]". And by "fairly good" I mean no loss of URLs AFAIK in their entire history.

Such stable URLs seem to be an instance of: if it's working, don't fix it, don't make extra work for people.

Contrasting example: OpenSocial just killed all their URLs in their handoff to W3C.

Background: my expertise comes from personally having 12+ years of personal experience maintaining stable URLs (date-time-stamped permalinks) at my personal domain, and longer than that for non-date-stamped URLs. I know nothing of w3id, nor of the longevity of anyone else's experience here with maintaining personal stable URLs, so I don't know how to evaluate other opinions.

from i-d.

@tantek, it is my understanding that when @elf-pavlik talks about "provide stable URI for all the terms in open controlled vocabularies", he not only talks about defining URIs, but for the ability to dereference them and get something back as a response. which is an entirely different issue, imho, but i think this may be the slight misunderstanding between the two of you. please correct me if i am wrong, @elf-pavlik.

from i-d.

On 2/24/15 3:59 AM, Erik Wilde wrote:

@tantek https://github.com/tantek, it is my understanding that when
@elf-pavlik https://github.com/elf-pavlik talks about "provide
stable URI for all the terms in open controlled vocabularies", he not
only talks about defining URIs, but for the ability to dereference
them and get something back as a response. which is an entirely
different issue, imho, but i think this may be the slight
misunderstanding between the two of you. please correct me if i am
wrong, @elf-pavlik https://github.com/elf-pavlik.

Yes, this is all about URIs resolving to descriptions of what they
identify.

Right now we have:

1. http://www.iana.org/assignments/link-relations/link-relations.txt
2. http://www.iana.org/assignments/link-relations/link-relations.xhtml
3. http://www.iana.org/assignments/link-relations/link-relations.xml
4. http://www.iana.org/assignments/link-relations/link-relations-1.csv

Simple solution options:

1. Tweak
   http://www.iana.org/assignments/link-relations/link-relations.xhtml by
   using <script/> to embed json-ld and turtle
2. Add http://www.iana.org/assignments/link-relations/link-relation.ttl
3. Add http://www.iana.org/assignments/link-relations/link-relations.jsonld.

I don't know who controls this domain, but the TURTLE and JSON docs can
be prepared very easily for incorporation and we are then completely set
with this matter.

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

from i-d.

@kidehen do you have any suggestions for mentioned earlier on this thread http://microformats.org/wiki/existing-rel-values (HTML5 spec uses it as official registry of link relations!)

please also notice earlier comment by @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.

and reply by @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.

from i-d.

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

from i-d.

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.

from i-d.

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.

from i-d.

@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

from i-d.

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 😞

from i-d.

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.

from i-d.

@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

from i-d.

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.

from i-d.

👍 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".

from i-d.

+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

from i-d.

@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.

from i-d.

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.

from i-d.

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?)

from i-d.

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

#40 is about the management of the registry itself.

from i-d.

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.

from i-d.