- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sat, 11 Jun 2016 17:07:47 +0200
- To: Sandro Hawke <sandro@w3.org>
- Cc: Ben <ben@thatmustbe.me>, Social Web Working Group <public-socialweb@w3.org>
- Message-ID: <CAKaEYhLbo9y6hOrtdn78ktOzcLBULH_Fq5BH7NiGuUNNofc9XQ@mail.gmail.com>
On 9 June 2016 at 17:45, Sandro Hawke <sandro@w3.org> wrote: > > > Melvin, I believe you're trying to be helpful, and I keep feeling like > we're close enough to a mutual understanding that I get tempted into one > more message, but my confidence that this discussion is a good use of time > is approaching zero. I suggest we agree to disagree, and drop it, unless > this message is some magical breakthrough. > > Last attempt below... > > On June 9, 2016 5:09:30 AM PDT, Melvin Carvalho <melvincarvalho@gmail.com> > wrote: > >On 8 June 2016 at 16:50, Sandro Hawke <sandro@w3.org> wrote: > > > >> > >> > >> On June 8, 2016 4:53:53 AM PDT, Melvin Carvalho > ><melvincarvalho@gmail.com> > >> wrote: > >> >On 8 June 2016 at 13:12, Ben <ben@thatmustbe.me> wrote: > >> > > >> >> > My recommendation at this point, is for this work to be a Note, > >and > >> >> leave the door open for further standardization. > >> >> > >> >> Isn't that effectively saying you want it resolved outside of the > >> >working > >> >> group? > >> >> > >> >No no! > >> > > >> >I think it's good work, in general. Im happy that it was done. > >Ideal > >> >way > >> >is to resolve issues here. It's slightly awkward with tantek having > >> >boycotted the mailing list, but I dont give up hope! > >> > > >> > >> The preferred place to discuss issues on a specific spec is github. > > I > >> opened an issue for you for this, to help encourage that, but then > >> eventually closed it because you weren't using it. > >> > >> >Just not seeing why it should be REC, rather than Note, at this > >point. > >> > > >> > >> Because it appears it will meet all the criteria for a Rec. > >Otherwise > >> it's like a 5th grade student being enrolled in the 2nd grade. You > >seem > >> to think it really still belongs in 2nd grade but it's already met > >the > >> objective criteria for graduating 2nd and seems fairly likely to do > >the > >> rest soon. > >> > >> >What I'd like to see is webmention having a mapping to linked data, > >> >interoperate with that, and the millions of sites that use it > >> >(including > >> >facebook and google), and also to have its form encoded version, > >seems > >> >to > >> >be the best of all worlds. > >> > > >> > >> Just because two systems use JSON-LD doesn't make them interoperable. > >> > >> Acting as if it does is the Semantic Web "handwaving" or "pixie dust" > >that > >> some folks find offensive. It's what creates the "RDF allergy". > >> > > > >Some folk may have an "RDF allergy", but if so I suggest that is > >minority. > >I was at one time an RDF skeptic. The mindset of an RDF skeptic is > >that it > >is a big time investment, and it's unclear that the pay off is worth > >it. > >Actually once you actually start using it (few people do) the pay off > >is > >really worth it. > > One question is how much you need to invest before there's payoff. I > think the RDF allergy comes from people investing some work and coming to > the conclusion it's a bad use of time. Arguably if they'd just spent a > few more weeks it would have started to pay off, but it's hard to know for > sure. > > Since you keep trying to argue from authority and personal judgement, you > might consider deferring to mine. I have some experience in this area. > Having worked with you for a while, I highly rate your analytic ability, and the way you can take a problem, get to the heart of the matter, and reframe it. You also have good in depth knowledge in a number of areas. But being a regular coder and user of these systems, on an hourly basis I think gives further insights that are not easy to communicate over email. At this point my comments are high level. > > Im part of the indieweb community, and I've hit all > >the > >walls there, you need something more powerful to start to scale, and > >RDF > >works. > > If you're going to make a claim like this and be useful, you need to tell > a true story about a wall you hit that you needed RDF to get past. > > What is needed for the indieweb community is an easy path to > Let's see if this works. My first use case was social. As part of the indieweb community I wanted to add friends to my roster. To may complete amazement there wasnt a way to do this. But a hope to expand the concept of "blogrolls". At this point I realized indieweb was a microblogging system, not a social system. I tried to develop things in this line but Tantek pushed back saying it was 'not a priority'. How can a social system not have friending. So I found this was much easier to do in RDF and Solid. That's just one example of many. I hope it does not because the focus of this thread, though. > >get > >started, then a smooth upgrade path for those that want advanced > >features. > > > >But anyway point is that all the linked data standards are > >deterministically translatable from one to the other without out of > >band > >knowledge. Out of band knowledge is a problem, and objectionable, when > >it > >can be avoided. > > > > > >> > >> There is adoption for ogp and schema.org in part because they're a > >whole > >> lot more constrained than just using RDF. The other constraints are > >> necessary to provide interop. > >> > > > >This is speculation. The fact is that these are significant > >deployments of > >linked data, and they are not alone. > > > >What is the deployment of webmention? What is the deployment without > >withknown -- under 100? I keep asking for statistics on this. I will > >assume silence to mean that webmention's deployment to be > >insignificant. > >This has to be factored into the overall evaluation. > > > > No, it doesn't. Same straw argument as on the other thread, plus > ignoring my point about how bad it is when your number of adopters falls. > OK, so you think adoption doesnt need to be factored in and I do. I think that's a reasonable thing to disagree on. You keep calling straw man but when I ask you why, you dont respond. It's not a good way to communicate, frankly. > > > > > >> > >> If you can show a plausible way to provide them for webmention, then > >I'll > >> be intrigued. I've thought about it a lot and don't think it's > >possible. > >> > > > >Im not sure what you're asking, but mapping webmention to linked data > >is > >possible, isnt it? > > > >In turtle: > > > ><> > > <http://www.w3.org/ns/webmention#source> <alice> ; > > <http://www.w3.org/ns/webmention#target> <bob> . > > > >In JSON-LD something like > > > >{ > > @context : "http://www.w3.org/ns/webmention", > > "source": "https://waterpigs.example/post-by-barnaby", > > "target": "https://aaronpk.example/post-by-aaron" > >} > > > >This is the definitive way to do this using w3c standards. These > >mappings, > >at a minimum, should be explicit. > > They are. > https://www.w3.org/TR/webmention/#uris-for-form-encoded-properties > > Again, please don't bother replying unless you have some new information. > Again we disagree. I said there should be an *explicit* mapping from webmention to a linked data format, so that implementors know what to do. In fact you are implying that if you prefix source and target in form encoded variables with a namespace it becomes isomorphic with a linked data serialization. It doesn't does it? This is under specified. > > - Sandro > > > > > > >> > >> - Sandro > >> > >> > > >> > > >> >> On Jun 8, 2016 6:59 AM, "Melvin Carvalho" > ><melvincarvalho@gmail.com> > >> >> wrote: > >> >> > >> >>> > >> >>> > >> >>> On 8 June 2016 at 11:28, Melvin Carvalho > ><melvincarvalho@gmail.com> > >> >>> wrote: > >> >>> > >> >>>> > >> >>>> > >> >>>> On 4 June 2016 at 02:02, Sandro Hawke <sandro@w3.org> wrote: > >> >>>> > >> >>>>> On 06/03/2016 07:15 AM, Melvin Carvalho wrote: > >> >>>>> > >> >>>>> I've attempted to communicate for the last year, on irc and in > >> >aarons > >> >>>>> github area, but its sometimes been not an optimal use of time. > >> >So I'd > >> >>>>> like to formulate my objections to webmention here, for further > >> >review, > >> >>>>> with hopefully some possible solutions. > >> >>>>> > >> >>>>> > >> >>>>> Hi Melvin, > >> >>>>> > >> >>>>> You've caught me at an excellent time to write a detailed reply > >-- > >> >I'm > >> >>>>> on the plane to the F2F meeting. This is just the right kind > >of > >> >work for > >> >>>>> this situation. Hopefully this reply will make everything more > >> >clear. > >> >>>>> > >> >>>>> It looks to me like your objections here are based on your > >design > >> >>>>> sense, your general sense of what good designs look like, > >rather > >> >than on > >> >>>>> specific concerns about use cases that can be addressed with > >one > >> >design > >> >>>>> versus another. > >> >>>>> > >> >>>>> In the most recent previous discussion on this topic, at > >> >>>>> https://github.com/aaronpk/webmention/issues/39, I repeatedly > >> >asked > >> >>>>> you to provide specific use cases, to explain how > >developers/users > >> >would be > >> >>>>> affected by some change you're proposing. I haven't seen an > >> >answer. > >> >>>>> > >> >>>>> Perhaps you thought I was just doing that as way of dismissing > >> >you, of > >> >>>>> giving you busy work? That's not the case. I was doing it > >> >because by > >> >>>>> arguing from uses cases, a group has a reasonable chance of > >> >reaching > >> >>>>> consensus. Arguing from design sense pretty much never leads > >to > >> >>>>> consensus. It's a bit like the difference between science and > >> >religion. > >> >>>>> With the scientific method, disagreements can usually be > >settled > >> >by > >> >>>>> replicating experiments and developing new ones. Not so much > >> >with > >> >>>>> religion. > >> >>>>> > >> >>>>> So, again, I'll say if you want to persuade the group of > >anything, > >> >I > >> >>>>> think you're going to have to lay out a use case. I suggest > >> >taking some > >> >>>>> part of one of the agreed-upon users stories and show how the > >CR > >> >version of > >> >>>>> Webmention doesn't work very well but some alternate version > >> >you're > >> >>>>> proposing does. > >> >>>>> > >> >>>>> Personally, I don't think you'll be able to do this. I've been > >> >>>>> thinking about this space, a lot, for years, and I don't see > >the > >> >issues > >> >>>>> you're raising as the kind of issues that could lead to > >material > >> >use > >> >>>>> cases. But you're welcome to try. > >> >>>>> > >> >>>>> A key question is what you're trying to do here. If you want > >to > >> >>>>> improve Webmention, that's probably the way to do it. If you > >> >just want to > >> >>>>> be a pain to the WG, you could raise a formal objection. (I'm > >> >not going > >> >>>>> to consider this "objection" a "formal objection" unless you > >> >specifically > >> >>>>> use that phrase.) But unless you can be more clear in the way > >I > >> >suggest > >> >>>>> above, I don't think that'll do anyone any good. Normally a > >> >Formal > >> >>>>> Objection is used to make a Working Group spend some time > >> >seriously > >> >>>>> reconsidering some decision it made. But I don't see a > >decision > >> >the WG > >> >>>>> has made around Webmention that it might change during a > >> >reconsideration, > >> >>>>> unless some new information was presented. > >> >>>>> > >> >>>> > >> >>>> Thanks for responding to my concerns. > >> >>>> > >> >>>> I was glad to learn that I am not the only person in the WG that > >> >has > >> >>>> reservations on this work. > >> >>>> > >> >>>> I dont feel the concerns have been addressed, other than the > >hand > >> >>>> waiving, "I dont find that compelling" argument, which can be > >said > >> >about > >> >>>> anything. I find this dismissive, and in this group, > >unfortunately > >> >I am > >> >>>> left with the feeling of relatively little recourse. > >> >>>> > >> >>>> I will leave this thread open a while to gather feedback and I > >> >think the > >> >>>> advice is to document exactly what the concerns are and put them > >in > >> >a > >> >>>> document, so they can be understood. Which I have begun to do. > >> >Much will > >> >>>> depend on how much time I have to do this. > >> >>>> > >> >>>> So, I think the issue here is that there are a number of people > >in > >> >this > >> >>>> group. Some are coding regularly in this space, and some are > >> >familiar with > >> >>>> existing W3C standards that solve this problem, but few are > >both. > >> >So > >> >>>> perhaps that can also be documented. > >> >>>> > >> >>> > >> >>> To clarify this is not a "formal" objection, because: > >> >>> > >> >>> 1 It would need to be clearly documented > >> >>> 2 It would need to be worthy of the attention of a wider audience > >> >>> (director + w3c member) -- that's not clear to me at this point > >> >>> 3 It would need fail to be resolved in the WG (I think we still > >have > >> >>> space to do that) > >> >>> > >> >>> I dont think 1/2/3 are currently met at this time. So I will try > >> >and > >> >>> build out (1) because I think there are legitimate concerns > >around > >> >interop > >> >>> > >> >>> My recommendation at this point, is for this work to be a Note, > >and > >> >leave > >> >>> the door open for further standardization. > >> >>> > >> >>> > >> >>>> > >> >>>> > >> >>>>> > >> >>>>> Another thing you could do is help move forward one of the > >> >alternatives > >> >>>>> to Webmention. Rhiaro mentioned in #39 how activitypub might > >be > >> >just > >> >>>>> what you want, and I understand there are several other > >possible > >> >directions > >> >>>>> one could go. > >> >>>>> > >> >>>>> A few more comments below, but the important part of my reply > >here > >> >is > >> >>>>> done. > >> >>>>> > >> >>>>> 1. Universality > >> >>>>> > >> >>>>> Axiom 0 of the webstates that we should use URIs to name > >things. > >> >>>>> > >> >>>>> > >> >>>>> I assume you're referring to TimBL's DesignIssues/Axioms > >document? > >> >>>>> That was written 20 years ago and reflects only one person's > >> >opinion. The > >> >>>>> W3C Recommendation in this space, a few years later, which > >> >resulted from > >> >>>>> extensive discussion among TimBL, the appointed and elected > >> >members of TAG, > >> >>>>> and many members of the public, was AWWW. I think you'll > >find > >> >AWWW > >> >>>>> includes a rather more restrictive and realistic version of > >this > >> >axiom: > >> >>>>> > >> >>>>> 2.1. Benefits of URIs > >> >>>>> > >> >>>>> The choice of syntax for global identifiers is somewhat > >arbitrary; > >> >it > >> >>>>> is their global scope that is important. The Uniform Resource > >> >>>>> Identifier, [URI <https://www.w3.org/TR/webarch/#URI>], has > >been > >> >>>>> successfully deployed since the creation of the Web. There are > >> >substantial > >> >>>>> benefits to participating in the existing network of URIs, > >> >including > >> >>>>> linking, bookmarking, caching, and indexing by search engines, > >and > >> >there > >> >>>>> are substantial costs to creating a new identification system > >that > >> >has the > >> >>>>> same properties as URIs. > >> >>>>> > >> >>>>> Good practice: Identify with URIs > >> >>>>> > >> >>>>> To benefit from and increase the value of the World Wide Web, > >> >agents > >> >>>>> should provide URIs as identifiers for resources. > >> >>>>> > >> >>>>> A resource should have an associated URI if another party might > >> >>>>> reasonably want to create a hypertext link to it, make or > >refute > >> >assertions > >> >>>>> about it, retrieve or cache a representation of it, include all > >or > >> >part of > >> >>>>> it by reference into another representation, annotate it, or > >> >perform other > >> >>>>> operations on it. Software developers should expect that > >sharing > >> >URIs > >> >>>>> across applications will be useful, even if that utility is not > >> >initially > >> >>>>> evident. The TAG finding "URIs, Addressability, and the use of > >> >HTTP > >> >>>>> GET and POST > ><http://www.w3.org/2001/tag/doc/whenToUseGet.html>" > >> >discusses > >> >>>>> additional benefits and considerations of URI addressability. > >> >>>>> From https://www.w3.org/TR/webarch/ > >> ><https://www.w3.org/TR/webarch/> > >> >>>>> > >> >>>>> I think it's pretty hard to argue that the strings "source" and > >> >>>>> "target" in Webmention posts should be URIs based on this > >advice. > >> > For the > >> >>>>> cases where one would want them to be URIs, a standard mapping > >is > >> >>>>> provided. You could view Webmention as using URIs for this, > >but > >> >during the > >> >>>>> POST, the namespace is left implicit. > >> >>>>> > >> >>>>> Most standards I know at the W3C adhere to this, > >> >>>>> > >> >>>>> > >> >>>>> Does HTML? Does CSS? Do any of the HTML5 APIs? Can you > >name > >> >a > >> >>>>> non-RDF spec that does? Probably best to stay away from > >XML > >> >specs, > >> >>>>> since their use of URIs is highly contentious. (As I > >understand > >> >it, XML > >> >>>>> only uses URIs as web addresses and unique identifiers, not to > >> >name > >> >>>>> things. The difference is perhaps pedantic, but it's clear > >XML > >> >specs > >> >>>>> don't align with the Linked Data Principles, which I think > >TimBL > >> >would > >> >>>>> agree subsumes Axiom 0 in his own personal design sense.) > >> >>>>> > >> >>>>> Probably not worth the time to go through this, but if I had to > >> >guess, > >> >>>>> I'd say by count 10% of W3C specs adhere to this (my groups > >like > >> >RDF, OWL, > >> >>>>> and RIF tended to produce a dozen specs at a time) and by user > >> >base, 0.001% > >> >>>>> of the W3C specs adhere to this. The weight of success is not > >on > >> >the side > >> >>>>> of this axiom, so it's not going to convince anyone. > >> >>>>> > >> >>>>> webmention does not use URIs for the source and target > >parameters. > >> >>>>> > >> >>>>> URIs can be derived out of band by reading the spec and using a > >> >prefix, > >> >>>>> but this is not ideal. > >> >>>>> > >> >>>>> > >> >>>>> Here's where, if you want to convince anyone, you have to tell > >a > >> >story > >> >>>>> about something that's important and significantly easier with > >> >source and > >> >>>>> target being URIs on the wire. I just don't see it. > >> >>>>> > >> >>>>> > >> >>>>> 2. Using form encoded messaging for the social web > >> >>>>> > >> >>>>> Views on this differ, but IMHO it's very clear that messaging > >over > >> >the > >> >>>>> social web according to our charter should be in JSON. > >> >>>>> > >> >>>>> > >> >>>>> The chairs and I have addressed the charter issue elsewhere. > >> >Please > >> >>>>> keep charter discussions in separate threads, since they > >involve > >> >different > >> >>>>> people and are reviewed differently. > >> >>>>> > >> >>>>> Webmention doesnt do this. > >> >>>>> > >> >>>>> To the extent that it's "just a signaling protocol" I suppose > >you > >> >could > >> >>>>> "get away with it". But I dont think webmention is by any > >means > >> >just a > >> >>>>> signaling protocol. It's an attempt to standardize messaging > >on > >> >the social > >> >>>>> web. > >> >>>>> > >> >>>>> > >> >>>>> How can you claim Webmention is "an attempt to standardize > >> >messaging"? > >> >>>>> I don't see that in the spec. I haven't heard that from the > >WG. > >> > I > >> >>>>> haven't heard that from the implementors. I haven't heard > >that > >> >from the > >> >>>>> users. Where are you getting that? > >> >>>>> > >> >>>>> I do, however, see how it could be *used* as part of a general > >> >>>>> messaging protocol: > >> >>>>> > >> >>>>> 1. System "Alice" wants to send system "Bob" some message M1 > >> >>>>> 2. Alice puts M1 on the web at URL U1, being sure to include > >some > >> >>>>> metadata the links to Bob. At a minimum, something like "To: > >> >Bob" (where > >> >>>>> Bob is a URL) > >> >>>>> 3. Alice does the Webmention thing, "mentioning" U1 to Bob > >> >>>>> 4. Bob gets the mention, dereferences U1, reads M1 > >> >>>>> > >> >>>>> So, in this sense, Webmention could be a key part of a web > >> >messaging > >> >>>>> protocol. It's has one advantage over the much simpler > >approach > >> >of "Alice > >> >>>>> POSTS M1 to Bob", namely that Alice is confirmed as the sender. > >> >>>>> > >> >>>>> But: > >> >>>>> - This isn't what Webmention was designed for; it's not clear > >> >anyone > >> >>>>> actually wants to use it for this. > >> >>>>> - If you do this, the actual message can be JSON or whatever > >Alice > >> >>>>> wants. The *message* is M1, published at U1, *not* the > >> >form-encoded > >> >>>>> Webmention that was posted to Bob. > >> >>>>> - If you want to do this, consider instead just POSTing M1 to > >Bob > >> >using > >> >>>>> some kind of authentication for Alice (eg OpenID Connect or > >> >WebID-TLS) > >> >>>>> > >> >>>>> So, I see no argument here against the current design of > >> >Webmention. > >> >>>>> > >> >>>>> > >> >>>>> Possible Solutions > >> >>>>> > >> >>>>> 1. Support JSON messaging -- the W3C has innovated in this area > >> >with > >> >>>>> some success > >> >>>>> > >> >>>>> 2. If we want to pass around messages using forms we should > >make > >> >the > >> >>>>> general case robust, scalable, extensible, interoperable and > >> >universal, and > >> >>>>> have webmention be an instance of such a system. That's > >possibly > >> >outside > >> >>>>> the scope and timing of this WG, I dont know. > >> >>>>> > >> >>>>> > >> >>>>> I'm not sure what those are solutions to, but they're probably > >not > >> >the > >> >>>>> problems Webmention is intended to solve. > >> >>>>> > >> >>>>> > >> >>>>> Im still being guided as to the difference between the REC and > >> >Note > >> >>>>> tracks, but I'll put the suggestion out there to move > >webmention > >> >to a note, > >> >>>>> or move it back from CR. I'm not an expert on this aspect of > >W3C > >> >process, > >> >>>>> but I'd like to raise these concerns to a wider audience, in > >> >particular, to > >> >>>>> folks outside the indieweb community. > >> >>>>> > >> >>>>> > >> >>>>> If you want people to pay attention to these concerns, either > >> >inside or > >> >>>>> outside the WG, I think you're going to have to develop a > >simple > >> >story > >> >>>>> about a problem that's solved with your modified Webmention and > >> >not solved > >> >>>>> with Webmention. Or a story about how Webmention being > >adopted > >> >would do > >> >>>>> real harm to someone. > >> >>>>> > >> >>>>> Frankly, I think you can find much better uses for your time if > >> >you > >> >>>>> want to work in this space, eg helping with activitypub. > >> >>>>> > >> >>>>> -- Sandro > >> >>>>> > >> >>>> > >> >>>> > >> >>> > >> > >> > >
Received on Saturday, 11 June 2016 15:08:19 UTC