Webmention message is not clearly mapped to linked data #51
Comments
|
cc @sandhawke |
|
I believe this is the same issue as #9? The outcome of that issue was adding a document at http://www.w3.org/ns/webmention and this sentence to the spec: What more is needed to "clearly map" the message to linked data? |
|
@aaronpk how would you write the webmention message in linked data? (pick any serialization that you prefer) |
|
@melvincarvalho Since you're more familiar with Linked Data perhaps you could provide an example? If there isn't enough information provided in that paragraph and in the namespace document to do so then maybe we can clarify those. |
|
Maybe two examples of how you could see it being serialized in json-ld? I
|
|
👍 for the constructive discussion by all participants in this issue! |
|
What's unclear? What's a reasonable interpretation of the spec other than @prefix : <http://www.w3.org/ns/webmention#>.
[] :source <https://waterpigs.example/post-by-barnaby>;
:target <https://aaronpk.example/post-by-aaron>.? Of course you're always free to assign one or more URLs instead of using a blank node, but that's your business. |
|
@sandhawke thanks for the example. A possible interpretation could be: or
How many implementors would have been able to work that out without the aid of an example? It wasnt immediately obvious to me. It may be that a blank node MUST be used, or MAY be used. There are some quite subtle things going on.
An example in the spec helps in a number of ways.
Why not agree on an example so that implementors will be able to understand how to do this. Also, although I prefer turtle personally, would JSON-LD not be more appropriate for this group? |
|
PS for those less familiar with linked data the example above might be instructive as to how it works. Essentially its a string of 3 URLs surrounded by <> to show key, value pairs tied to a subject. You can also have say a string as an object and you would put them in "" instead of <>. I mention this because I started out thinking the semantic web was super complex and it took me quite some time to realize that it's actually super simple and boils down to the above. |
|
The problem with making those design decisions is that we don't have use cases for this on which to make those decisions. At least I haven't seen any uses cases that make sense to me and involved interoperating using webmentions written in an RDF syntax. The problem with providing an example is that people might think they MAY send webmentions that look like that, but that's not true. |
|
It is easy to construct a use case. Alice is using a system that supports AS2 or Solid or Web Annotations or LDP or any number of the growing Linked data systems. Someone mentions her in the comments of a post of another person's, and she would like to see when people are talking about her. In fact I came across this very problem in solid social it's also a natural way to grow social network participation. I would like an example to send to Alice's server so that she can become aware that she was mentioned. What is the JSON LD that I send? Here is where an example would be needed. This is underspecified, and it's up to the authors to decide. Possible sensible choices here.
Webmention message should be able to work, with those implementing AS2, rather than reinventing the wheel. An example is needed for this. |
|
Clarification of "Webmention message should be able to work". Probably better to read : "the webmention message semantics should ..." |
|
@melvincarvalho You may wish to read this very thorough documentation of a live implementation that uses the existing Webmention spec to send notifications between JSON-LD documents: http://lombardpress.org/2016/04/16/iiif-webmentions/ He was able to make a system that interoperates with other JSON-LD servers, and seems to have no problem sending the form-encoded webmention payload to do so. I encourage you to implement sending and receiving webmentions with this implementation to get a sense of how a real world implementation works with JSON-LD documents. |
|
@melvincarvalho that use case demonstrates exactly why an example would be harmful. If someone tries to send a webmention encoded in json-ld (or anything other than form encoding) the receiver isn't obligated to understand it. By advertising an endpoint with rel=webmention I'm promising to understand form encoded webmentions, no more. If you want to advertise an endpoint that commits to more than form encoded source and target, use a different rel. That's what I keep telling you. Webmention is what it is, and if you want something else, like something with authentication or json-ld, which are totally reasonable things to have, then just do that (with some other rel). It's not helping anyone to try to turn webmention into something different. |
|
@sandhawke I disagree with this. It's rather a bad idea, from an implementation perspective to have two different endpoints, one that understands JSON and one that understands form variables. And it's perfectly reasonable to have an endpoint that understands a variety of formats. In most languages it's quite easy to switch on the payload that you get, to determine what it is. This groups is already developing endpoints around JSON-LD, around AS2 and this effort is proposing form encoded variables. I think it's just about OK if webmention is a note. But a REC could be dangerous. Consider drupal or wordpress being persuaded to adopt it. Now you have a massive DDoS attack that this work is not able to counter as it stands. It will need to innovate work such as signatures or verified claims, which is already going on in the W3C, and being serialized in JSON LD. You may have a differing opinion on this (and its ok to disagree), but I think it would be a mistake to reinvent the wheel here. And have two efforts and/or fork the WG. The "doubles" version should be a flattened form of the "triples" version. By its very nature the triples version is more expressive, and information will be lost going one way to another. So come up with a triples example, and that's canonical. Then have the doubles version unchanged. |
|
@melvincarvalho I don't agree with your theories about how protocols can evolve in place. But I've said that many time before in many ways, and this is going in circles, yet again and again and again, so I'm done done done. Meanwhile, if you see a DDoS attack vector with webmention, then raise that as it's own issue, unrelated to RDF. Maybe it'll turn out that the solution involves adding RDF, as you seem to think. |
|
@sandhawke thanks for your input. I know you feel strongly here, so we'll have to disagree on this one. To avoid needless repetition I suggest the DRY ("Dont repeat yourself") principle. re: webmention spam, it is an acknowledged issue and an issue ( #27 ) on DDoS was previously opened. I think the resolution was that we dont know how bad it will be, and that the vouch extension may be a way to help. I dont really know what my supposed theories about "how protocols can evolved in place" are or what that means, so I'll take your word for it. Linking this back to the original thread my concern is about interoperability. What's clear is I think it's more of an issue than you, and that's fine. What I would want to see is the authors of this spec (and perhaps you) agreeing how this would look in JSON-LD ... maybe even writing out an example in a github issue would be valuable for implementors? I ask because there are a number of ways of doing it. What do you think? I know you are a fan of examples. So I thought of a practical one that we've discussed in Solid. How does a user login to a site using the user@host type memorable identifier? Well many of us here implemented webfinger and I think it's fair to say that consensus was that it's not a well liked protocol. You could use webmention here in a two step process.
Abstracting this principle whenever you would like a server to know about a "rev" style link where typical follow your nose will not yield the knowledge you need, you can send the target a "hint" which will be useful in future. I hope this example demonstrates that this type of message (im talking about the message body here, and not the protocol) has wider applicability in the social web, and would be appropriate in use cases for linked data based systems. And vice versa. |
|
Proposal: @prefix : <http://www.w3.org/ns/webmention#>.
[] :source <https://waterpigs.example/post-by-barnaby>;
:target <https://aaronpk.example/post-by-aaron>.Given a lack of other suggestions, should we take this (Sandro's suggestion) as the official canonical example in linked data of a webmention? EDIT: replaced the word "form" with "example" |
|
Why would you need this to be in json-ld at all? (for the webmention part) The server fetches and parses the linked data from the users homepage. The server can store that data any way it chooses, thats outside of the spec. The webmention is just telling the server to fetch that page. So all it has to do is implement a webmention endpoint per the spec. To rewrite your example a little.
Interesting to note, If you remove logging in with user@host and instead login with the homepage url, this looks a LOT like indieauth. Instead just fetch the data when the user types their homepage url in to a login form. I would also note that this example doesn't really make sense unless the home page is linking to the server it sends the webmention to, otherwise, there really isn't a mention and the server wouldn't generally send a webmention. |
|
@melvincarvalho Would you please give this document that @rhiaro wrote a read and see if maybe this answers your questions? https://github.com/rhiaro/wm-ldp/blob/master/index.md |
|
@aaronpk this actually highlights this issue. @rhiaro and @sandhawke have written it out in slightly different ways. The implication is that there's an clear and obvious way to do this. This shows that is not the case. This potentially confuses implementors and harms interop. Pick an example and just go with that.
|
|
Giving people an example like this would provide a false illusion of interoperability. |
|
Unless I am mistaken about how Turtle is parsed and is able to interop, both their examples end up being equivalent. In any case, I am happy to end this thread by recommending people read @rhiaro's document. The Like @sandhawke said, putting an example of a payload that is not form-encoded into the spec would actually do more harm than good. |
|
Aaron, Rhiaro's example serialization and mine are different in a way that would often not matter, but might in some deployment situations. Without having real use cases, I'm there's no way to say which would be better. |
|
Melvin, it would be good to have the working group make a final decision and wrap up this issue. It sounds like you might be ready to make a concrete proposal. If so, please do that. |
This confirms what I have been stating ie that webmention is not interoperable. That's my concern. I would propose to:
|
|
@aaronpk thanks for pointing out the context is live in http://www.w3.org/ns/webmention {
"@context": "http://www.w3.org/ns/webmention#",
"@type": "Webmention",
"source": "https://waterpigs.example/post-by-barnaby",
"target": "https://aaronpk.example/post-by-aaron"
}This one ^^. Note: I think in Amy's document to align with this and sando's example the <> should be a []. <> means properties of the document (so we dont know actually that document is, probably the newly created resource). [] means blank / empty. It probably doesnt make sense to tie source and target to an HTTP document anyway. |
|
I'd like to point out one advantage of this serialization for practical use. The type = Webmention allows you to create a generic resource that can receive all kinds of incoming messages. It also future proofs the data structure against name clashes in two ways, one showing that the JSON object is a webmention. The other, more importantly, is that the JSON objects can be easily stored and retrieved via the type, as part of a bigger knowledge base. This is very useful, for example, when using in memory data stores. |
Interoperability only makes sense in a context. With a good standard, all implementations of it are interoperable with each other. One of the more prominent early uses of the word was in the TCP Interoperability Conferences (I vaguely recall the first one, in Monterey, in 1987), which as I recall were inspired by earlier informal "bake-off" sessions where people got together to see if they could get their TCP implementations to talk to each other properly. By 1987 the community was getting too big to do that. The series turned into Interop, which I guess is still going strong. Wikipedia says, "For every US event, Interop volunteers build a network (called the InteropNet) using tools from various vendors to demonstrate the latest technologies and interoperability." It makes sense to have have each TCP implementation work with each other TCP implementation. That's how the Internet works. If the TCP implementation on your server isn't interoperable with the the TCP implementation on my laptop, then my browser may not be able to properly connect to your webserver. On the other hand, the UDP implementation on your server would never be interoperable with the TCP implementation on my laptop. They're different protocols. One would never expect them to interoperate. It makes no sense for them to interoperate. If you say you're making your UDP implementation interoperate with my TCP implementation, then I say that sounds like you're actually making a TCP implementations. If you're saying you want to make your OSI system (the Internet's competition at the time) interoperate with TCP, ... it's kind of nuts, because it's a different stack. TCP fits on top of IP. Running TCP on top of X.25 or something, ... well, that would be a terrible design, at best. So when you say you want webmention to be interoperable, you have to say what you want it to be interoperable with. I think webmention interoperability is fine, because all evidence suggests webmention implementations are doing fine at interoperating with other webmention implementations. What you actually say in the issue introduction, is you want it to be interoperable with "linked data", but that doesn't really parse. Rhiaro's text shows it's easy to make webmention interoperate with linked data systems. It's like you're trying to make TCP interoperable with JSON. The whole concept is misguided nonsense. I keep thinking if I explain it a little more, you might come to understand it. Very frustrating. In any case, your proposal is out of order. It's already been decided that we wouldn't use JSON-LD as the syntax. |
Yes, I agree. interopable is perhaps a loaded term which can evoke emotion. In order to achieve a balanced conversation I'd suggest avoiding terms like "nuts" or "misguided nonsense" I appreciate you sharing background but I also have some experience in the social web, being an author of the XG report, the only person on every call there, and having spoken to many people in the social web, one on one. The fact is, most systems think they are interoperable, but there are barriers and artifacts that get introduced that caused a balkanized social web. I am trying to help to break down those barriers.
That's not accurate. TCP is a transport protocol, and JSON is a serialization. I am trying to align the serialization so that different aspects of the social web can know how to work together by way of example. Given that we have a triple style serialization that plays well with a number of other groups, both in this WG and the W3C, we should create an example so that those implementors know how to send this kind of message. There may be a slight loss when going from triples to doubles, but that's OK. At a minimum I would like to agree on what such a thing looks like. There have been differing suggestions here, and I have proposed one. It's not as easy as it first seems. The first step is simply to write out an example we can agree on. I have proposed one.
I thought I did at the top: "that can be implemented by those working with web standards such as JSON LD, Turtle, AS2 etc." Please dont feel frustrated, I am trying to listen to you, but it's possible for people to disagree on the topic of interop. Essentially I'm trying to build bridges, rather than, create islands.
Let's break down my proposal into two parts then.
At a minimum I think (1) is helpful and please take a look at my proposal above for it, or make a counter proposal. Im totally open to ideas. |
|
Let me just quote openstand which W3C is a member of (I beleive):
I'm not trying to score points here, just give an idea of what the word interoperability means to me. |
What are you trying to build a bridge to? What system would want to interoperate with webmention that can't just speak webmention? There aren't any, because it's really easy to speak webmention. You're not trying to build bridges between islands, you're trying to tell people to build bridges in a different way because someday somehow maybe it'll make things easier for someone. That's helpful to a point, when it's possible they haven't considered what you're saying, but at some point it becomes rude and annoying.
Those are all orthogonal to webmention. The webmention spec already says everything one needs, as far as I can tell. If it's missing something, maybe it's missing a section on how all the things you're saying are irrelevant, but I have no idea how to write that in a way that makes sense to you, despite oh so many attempts. If you want to communicate via JSON or AS2 or JSON-LD or natural language text or whale song, you put that content on the Web. Then, if you want to tell someone about it because that content is about them, you send them a webmention. Those two parts are entirely orthogonal. One could hypothetically have an alternative version of webmention that used JSON-LD instead of form encoding, but that would be more complicated for no benefit that's not full of handwaving, and the WG has already decided against that.
Weeks of being as clear and patient as I can have completely failed to register on you at all. I thought maybe that more dramatic language would help you realize how your behavior looks to me, and perhaps get you to reconsider your actions here. |
But it's not as simple as just putting an example of the serialisation in the spec. If we did that, we'd have to describe how a webmention endpoint should handle it, too. With that, comes a bunch of other considerations.. basically another spec. A different spec, for generic message passing in linked data, outside of webmention's well defined scope. I agree that's important, and you're invited to help work on it. But it's not webmention. |
You opened your dialogue on this issue with "If you just want to be a pain to the WG". If this is being as clear and patient as you can, I would not wish to see you in an impatient mood. I will reiterate that your tone is not conducive to a productive dialogue.
As above. What is clear is that I consider interop with LD an important issue and you dont. This has been established. My aim in this thread is not to argue with you. My aim is to write out an example in JSON LD, which you originally said you'd help with. And that you wrote out in turtle. There is also a similar way that Amy wrote it. Aaron provided some useful information in that the LD context is there. My aim is to pick one serialization between yours and Amy's and write in LD. Ive made a number of suggestions and proposals here. It would be helpful to either agree with one of them, ask for clarification, or propose an alternative. @rhiaro whether or not the example should go in the spec, I think it's valuable to have an example written down somewhere at least, and a github issue was suggested instead of the mailing list. What do you think about my suggestion of using the serialization in your document but replacing <> with []? |
|
To clarify Proposal 1 {
"@context": "http://www.w3.org/ns/webmention#",
"@type": "Webmention",
"source": "https://waterpigs.example/post-by-barnaby",
"target": "https://aaronpk.example/post-by-aaron"
}Proposal 2 {
"@context": "http://www.w3.org/ns/webmention#",
"source": "https://waterpigs.example/post-by-barnaby",
"target": "https://aaronpk.example/post-by-aaron"
}Is there any preference between these 2? I favour proposal 1. |
|
@rhiaro what do you think about putting such an example in the webmention namespace vocab document? |
|
Repeating myself: I'm strongly opposed to the WG endorsing an example, because it would cause more problems than it would solve. Also, you agreed your use of the term interop was misleading, then you went ahead and kept using it. |
Could you elaborate on what problems it would cause? Are they things you've run into, or theoretical issues? |
|
People tend to think examples in a spec are something that should work. So if we put an example in the spec, people might think it would work. But since Webmention endpoints don't accept JSON-LD, the example won't work (on a typical webmention endpoint). To me, that sounds like a problem. |
|
I agree that misleading examples are a problem. But this problem can be reduced by including an appropriate comment in the example. |
|
What would it say? " Here's a thing you shouldn't do with webmention" ? Maybe a big red X over it? |
|
I think a better way to resolve this, now that we have accepted Linked Data Notifications as an Editor's Draft, is to transfer this issue there and close this one with no changes to the Webmention spec which is already in CR. That is, Linked Data Notifications should document mapping Webmention to linked data, rather than asking a mature spec that has no other mentions or even informative LD dependencies to do anything. @rhiaro if that sounds ok to you, could you open an issue on Linked Data Notifications accordingly? @melvincarvalho you indicated in #social WG IRC today that accepting Linked Data Notifications as an ED and documenting a mapping would be acceptable to you as a resolution to this issue (51). http://socialwg.indiewebcamp.com/irc/social/2016-07-05/line/1467741287976 |
|
LDN actually already has a webmention example in json-ld. I'll also document how to convert between them in SWP if that seems appropriate. |
|
@tantek, procedurally and socially, I think it's better to have commenters close their own issue if they're satisfied. |
In that case would it be reasonable to take at two step approach. You did say on the ML
|
|
And my reply is, again and again and again, the webmention spec is not the right place for this, because RDF is not part of the webmention protocol. Above, you've been told two places that are the right place for this. Please take your input there, and close this issue. |
|
@sandhawke I disagree with your analysis. My original post states that webmention lacks interoperability. I have gone over why this is advantageous. It is possible that I am over rating the importance of interop, but Im not persuaded of that. The W3C does have a commitment to interop. This would be perhaps an interesting meta discussion. Therefore, my original objection stands. If a disinterested party were to weigh in on the topic of interop I would be willing to be persuaded. I've not been persuaded by your argument that a mythical developer will misread the spec, in such a way as to send JSON to a webmenion endpoint and get back an error message. Is there any evidence for this? And given content negotiation is both fundamental to the web, and to cross origin messaging, it is a reasonable expectation for endpoints and developers to be able to work with multiple formats. In any case, I would like to come to a consensus on what a webmention mapping example would look like in JSON-LD and this has been seconded on this thread. Where do you suggest raising an issue for this as we have 3 proposals now. |
|
Closed as requested, pending new information. Would still appreciate pointers regarding my question above on where to map out webmention to linked data. |
|
@melvincarvalho In progress in SWP, see commit as a start ^ |
The webmention spec lack interoperability with linked data.
What is needed is an explicit translation of
source=https://waterpigs.example/post-by-barnaby&
target=https://aaronpk.example/post-by-aaron
Into a format that can be implemented by those working with web standards such as JSON LD, Turtle, AS2 etc.
While the spec clarifies the namespace that could be used in the predicate position. The mapping remains unclear for implementors and needs to be stated explicitly.
It is clear that webmention alone suffers from the "webmention spam" problem leading to possible DDoS attacks. The argument I have heard is that while webmention is small, it's not a problem, but if it becomes a W3C REC extensibility will become critical. The samlention and vouch system essentially are replicating work done elsewhere in the W3C such as digital signatures and verifiable claims. Rather than replicating this work twice, or forking the working group, I would strongly suggest aligning the work now by adding an example to the spec to explicitly show how implementors can send source and target to a server using linked data (JSON-LD might be a good fit).
But this mapping is currently under specified. I suggest using this issue to come up with the closest mapping possible.
The text was updated successfully, but these errors were encountered: