there is still a problem with this proposal in that it is not clear what the subject of the attribute/values is. One would need to define this generally enough so that it functions with all urlencoded parameters. See issue 11: clarifying URLEncoded form meaning

@melvincarvalho Would it resolve your concern (and this issue) to add something like this (exact verbage left to editor) to the specification?

Webmention-receiving services that store or republish the 'source' and 'target' properties as URIs SHOULD do so using http://purl.org/net/pingback/source and http://purl.org/net/pingback/target.

@gobengo

• it's unlikely that this will be accepted by the IndieWeb folks, as they will argue that it is ugly
• it partially answers the problem here but not fully as per my previous remark that it is not clear what the subject of the request is
• it won't scale to more cases ( see issue clarifying URLEncoded form meaning #11 ), meaning that there would be even less reason for it to be adopted by the IndieWeb folks, nor for it to make that much sense to the w3c.

I was gonna suggest similar to @gobengo, plus the webmention rel value could be mapped to pingback:to.

@bblfish The spec says upon receipt of a webmention a URL must be returned, so the subject of source and target would presumably be that URL - the 'webmention object' (a pingback:Request?). (will send a longer reply to #11 later).

@gobengo assuming that's the ns used, that would work yes. However, there's talk of purl.org being revamped. So it would be good to get consensus on where to put it. But in principle, yes, that sounds like improved text.

@bblfish agree with all your points. But the subject issue was not raised here, let's follow that up in #11 and perhaps try and resolve just "source" and "target" in this thread. Re: "indieweb folks" accepting it, Im an indieweb folk and so is amy, so that's a good start.

@rhiaro the subject of the webmention is something like

<#subject>  <:source>  <URL>

Now if it's not mentioned we can assume it's an anonymous or blank node. That's ok as linked data permits blank nodes, tho many consider it an anti pattern.

@rhiaro

the subject of source and target would presumably be that URL - the 'webmention object' (a pingback:Request?). (will send a longer reply to #11 later).

It seems to be that pingback:Item is more fitting than pingback:Request, which is linked to as http://purl.org/net/pingback/Request, but 404s

@melvincarvalho

However, there's talk of purl.org being revamped. So it would be good to get consensus on where to put it.

Cool. I suppose I'm implicitly proposing trying to make use of the existing pingback vocab instead of introducing a new one (until/unless we see a great reason the pingback vocab won't be sufficient). So hopefully nothing new will be created that has to be put somewhere new.

To summarize so far it seems like

• This is a reasonable issue to try consider in order to enable LD federated protocol users
• It can be addressed by adding one sentence, probably just pointing to an existing vocabulary. No new MUSTs required by webmention.

@gobengo For when purl.org is down, the actual SP vocab is here: http://dssn.org/pingback/ns/namespace.html. Probably not the best place to be debating the semantics of the terms, but pingback:Item has seeAlso to pingback:Container (which I believe is a type for the endpoint itself?) so that doesn't feel right to me, although none of them have descriptions so it's not clear what's intended.

For when purl.org is down, the actual SP vocab is here

Right but the namespace URI is still http://purl.org/net/pingback/. I agree that the canonical document that describes that namespace can/should be somewhere that stays highly available.

pingback:Item has seeAlso to pingback:Container

Oh I assumed 'seeAlso' was just 'this is relevant' not 'this is equivalent'.

I think we're essentially agreeing so happy to let this rest.

Can someone clarify the distinction with #10 please? This issue is /only/ about republishing once received?

This is a particular answer to the problem discussed in #10 , which lists a number of different answers.

@jasnell what was the mechanism/language you used to use a default namespace (base URI) for property names in Activity Streams? I'd like to add a similar paragraph to Webmention to resolve this issue.

Will add this to the appendix:

URIs for form-encoded properties

If your implementation wants these to be a URI, prefix them with http://w3c.org/ns/webmention#

Minor correction: http://www.w3.org/ns/webmention#

oops thanks!

Added! http://webmention.net/draft/#uris-for-form-encoded-properties

@melvincarvalho We discussed this issue during the March F2F meeting. I've updated the spec to address the issue, giving guidance on how to turn the parameters into URIs. Please take a look at the revised text here and comment here whether this is acceptable. If not, you may reopen the issue and provide more information about what change is requested and why.

@aaronpk thanks, that looks like an improvement, and it would help resolve interop issues.

First comment is that ( http://www.w3.org/ns/webmention# ) gives a 404 right now.

What's the consensus regarding reusing the pingback ontology, as I think it already contains all the terms used in webmention?

I think @csarven has done some work here on the solid notifications spec and implementation, and may wish to weigh in.

@aaronpk ... my apologies, I just saw the mention on this and the question about the default namespace. I'm not 100% certain what you're asking for tho. Can you clarify?

@jasnell thanks, we discussed during the f2f and came up with the language I added to the appendix.

@melvincarvalho I can't find a reference to namespace used for the Pingback terms. Can you point me to it?

@sandhawke Is there something we need to put at http://www.w3.org/ns/webmention for this? How would we go about that?

@aaronpk @sandhawke I'm happy to take charge of putting the LD-friendly representation of terms up at www.w3.org/ns/webmention

@melvincarvalho SP has source and target but also a bunch of other constraints that might not apply to webmention. For people interested in the LD side of this we should probably have a separate discussion sometime. We can always include equivalence to related terms in the wm namespace if appropriate.