Re: Federated/Distributed @mentions

Let's look at the problem a different way: I'm a social application
platform. A user hands me some arbitrary piece of content (a blog
post, a wiki page edit, a status update, etc). When I get this
content, I want to create an Activity that communicates to the rest of
the world that something happened. Looking at the content, how am I
supposed to know that it contains a mention? Is the user only allowed
to mention people my system is aware of? If not, how do I determine
who or what is actually being mentioned. In order to mention people,
does the content the user give me HAVE to be HTML? If it's not HTML,
how do I determine what is a mention and what isn't?

Once I receive that content and make the determination that it
contains a mention, whatever I do afterwards really is not all that
important. I can set the audience targeting fields, add things to the
as:tag property, send appropriate push notifications, etc. None of
that is really all that critical to scope out.

The options put forward so far seem reasonable to me:

1. If it's plain text content, using @[id|display] is straight forward
and simple. My application can look at the plain text, determine what
is going on, and just do the right thing.

2. If it's HTML, some embedded microdata with
itemtype="http://www.w3.org/ns/activitystreams#Mention" or
typeof="Mention" or class="h-mention" or whatever works just fine.

3. If it's JSON-LD, using the audience targeting and tag properties work great.

The key point is that given these three types of content, I can have a
reliable means of examining the content and determining that it
includes a mention.

- James

On Thu, Dec 4, 2014 at 4:18 PM, Owen Shepherd <owen.shepherd@e43.eu> wrote:
> What's the semantic of mentioning somebody? Is my message supposed to be
> delivered to them, etc? Can I mention a non-entity? How does all of this fit
> together with tags? (I think the latter are probably orthogonal).
>
> Now, with that out of the way:
>
> If the purpose is to involve somebody in the conversation, then the correct
> method is to address them, by placing them in the "to" or "cc" property of
> the object
> If the purpose is just to let somebody know that they were mentioned, then
> we should of course add a mention property to the ActivityStreams schema.
>
> Now, I would suggest that, for the latter:
>
> There is a "mentions" property, which indicates that this object mentions
> something else (this would presumably be a list/in RDF, permitted to have
> multiple values)
> There is a "mention" activity, which is how the protocol lets you know that
> you were mentioned
>
> Now, as for "inline in content" metadata
>
> ActivityStreams' "content" property is HTML. That should be our primary
> focus. I don't really see a need for a method for encoding mentions in
> "plain text" content, because ActivityStreams doesn't carry such content
> The ActivityStreams schema is a linked data schema, which means that we can
> use RDF-y things to reference it. So it would seem that the natural syntax
> for mentioning somebody in HTML would be something like RDFa. In the RDFa vs
> Microdata comparison, RDFa wins here because it supports multiple
> vocabularies in a much smoother manner, doesn't have the impedance mismatch,
> and is a W3C REC.
> Therefore, I would suggest that we make a non-normative recommendation that
> producers mark up any inline mentions in RDFa, preferably Core 1.1. This
> would end up looking something like
> The ActivityStreams 2.0 spec editor is <a property="as:mentions"
> href="http://www.chmod777self.com/">James Snell</a>
> (or, for things which have an "@id" not equal to their URI)
> One of the chairs of the W3C Social Working Group is <a
> property="as:mentions" resource="acct:evan@e14n.com"
> href="https://e14n.com/evan">Evan Prodromou</a>
>
> Thereby any agent which wants to implement custom display can find the
> "as:mentions" properties, look at their target, and annotate them
> appropriately.
>
> For tags.. I'm not sure of the value of inline tagging at all for us. Its
> something Twitter does because of its' intentionally constrained environment
> that I'm not sure we should emulate. That's not to say that an implementaton
> can't emit hashtag references or whatever, but I'm not sure what utility we
> get from some form of inline tag referencing. Tagging is meta data of the
> purest form.
>
>
>
> Owen Shepherd
> http://owenshepherd.net | owen.shepherd@e43.eu
>
> On 4 December 2014 at 17:40, Ben Werdmüller <ben@withknown.com> wrote:
>>
>>
>> Theoretically I'd implement plain-text, HTML and JSON-LD versions, and
>> these suggestions seem reasonable. (In practice, I'd also add mf2 markup,
>> but of course, this is perfectly compatible with that.)
>>
>> I guess the thing I'm still concerned about is denoting mentions with an
>> @-sign. Is that a convention we're happy to accept across all platforms? Is
>> there a way for other platforms to say "I actually use a + or a ~ instead"?
>>
>>
>> On Thu, Dec 4, 2014 at 4:53 PM, James M Snell <jasnell@gmail.com> wrote:
>>>
>>> While I'm sympathetic to the HTML-markup approach being "the most
>>> flexible" option, I definitely question whether it's the right answer
>>> in all cases. For instance, if I'm sending a JSON-formatted push
>>> notification to a native mobile application, why would I force the
>>> application to use an HTML parser to extract the necessary metadata
>>> from a short snippet of text when a regex would do just fine? Second,
>>> it can become extremely verbose. Yes, I'll grant that when the
>>> @mention is actually rendered to the user in HTML it ought to be
>>> converted to a microdata/microformat type structure, but it should be
>>> possible to do in "plain text" also.
>>>
>>> Perhaps, then, we define things so that they can be represented both
>>> ways, with a simple translation between them:
>>>
>>> Mentions:
>>>
>>> In plain-text:
>>>   @[http://www.twitter.com/jasnell|jasnell]
>>>
>>> In HTML:
>>>   <span itemscope
>>> itemtype="http://www.w3.org/ns/activitystreams#Mention">
>>>     <a itemprop="href" href="http://www.twitter.com/jasnell">
>>>       <span itemprop="displayName">jasnell</span>
>>>     </a>
>>>   </span>
>>>
>>>   (or)
>>>
>>>   <span vocab="http://www.w3.org/ns/activitystreams#" typeof="Mention">
>>>     <a property="href" href="http://www.twitter.com/jasnell">
>>>       <span property="displayName">jasnell</span>
>>>     </a>
>>>   </span>
>>>
>>> In JSON-LD:
>>>
>>> {
>>>   "@context": "http://www.w3.org/ns/activitystreams",
>>>   "@type": "Mention",
>>>   "href": "http://www.twitter.com/jasnell",
>>>   "displayName": "jasnell"
>>> }
>>>
>>> Hashtags:
>>>
>>> In plain-text:
>>>   #[http://www.twitter.com/hashtags/socialwg|socialwg]
>>>
>>> In HTML:
>>>   <span itemscope itemtype="http://www.w3.org/ns/activitystreams#Tag">
>>>     <a itemprop="href" href="http://www.twitter.com/hashtags/socialwg">
>>>       <span itemprop="displayName">socialwg</span>
>>>     </a>
>>>   </span>
>>>
>>>   (or)
>>>
>>>   <span vocab="http://www.w3.org/ns/activitystreams#" typeof="Tag">
>>>     <a property="href" href="http://www.twitter.com/hashtags/socialwg">
>>>       <span property="displayName">socialwg</span>
>>>     </a>
>>>   </span>
>>>
>>> In JSON-LD:
>>>
>>> {
>>>   "@context": "http://www.w3.org/ns/activitystreams",
>>>   "@type": "Tag",
>>>   "href": "http://www.twitter.com/hashtags/socialwg",
>>>   "displayName": "socialwg"
>>> }
>>>
>>> - James
>>>
>>> On Thu, Dec 4, 2014 at 4:21 AM, Ben Werdmüller <ben@withknown.com> wrote:
>>> >
>>> > We've been considering various options for this in Known. I strongly
>>> > disagree with using Markdown or similar syntax for human-readable
>>> > content,
>>> > because that creates a burden to support a wholly different notation in
>>> > applications that are almost certainly web-based at some level. I do
>>> > think
>>> > HTML with embedded microformats / microdata is the most flexible option
>>> > for
>>> > this scenario. (It also doesn't tie applications into Twitter-style
>>> > @-syntax
>>> > - there's no need to let them dictate the convention.)
>>> >
>>> > Dave's approach for structured data also makes sense to me. You include
>>> > the
>>> > bare content, and then metadata that allows you to apply your own
>>> > markup,
>>> > rather than including some other microsyntax in bare text. That again
>>> > gives
>>> > application developers the most flexibility, although I would go so far
>>> > as
>>> > to change "username" to "@foo" in his example, to also allow different
>>> > notations. It then becomes a simple search and replace, with a strong
>>> > suggestion that usernames are prefixed with some notation to prevent
>>> > accidents with greedy searches.
>>> >
>>> > On Wed, Dec 3, 2014 at 7:36 PM, Dave Wilkinson <wilkie@xomb.org> wrote:
>>> >>
>>> >> How does this work when people put HTML as the content? Does this get
>>> >> parsed before or after entities are parsed? What happens when agents
>>> >> that
>>> >> see this as html don't parse them out?
>>> >>
>>> >> You'd have to really lock down how to parse the content field and what
>>> >> is/isn't acceptable there and what to do to remove ambiguity when you
>>> >> actually want some of that syntax to be untouched.
>>> >>
>>> >> I'd assume this isn't about routing. We have solutions for that. You
>>> >> just
>>> >> tag the object with who is mentioned, who it is going to, what it is
>>> >> in
>>> >> reply to, etc.
>>> >>
>>> >> This is just about marking up the content, which can currently be in
>>> >> any
>>> >> form? Right now, you'd just have "@foo" in your content, and the
>>> >> object
>>> >> would have an array of mentions which you would use to map the
>>> >> username to a
>>> >> domain and you would just mark it up as you need to. The convention is
>>> >> to
>>> >> look for an @ sign, although we don't (nobody does) specify the valid
>>> >> characters for a handle.
>>> >>
>>> >> The only better way I can think of is not to enforce some new markup
>>> >> language semantics within already arbitrary markup, but rather to just
>>> >> simply place in that mentions array the position and length of the
>>> >> substring
>>> >> in the content that represents the handle. Then I'd just replace that
>>> >> substring with my markup, whatever that is for my purpose, or if I
>>> >> don't
>>> >> care, I just display the content with whatever the publisher cared to
>>> >> use
>>> >> ("<a></a>" tag, @foo, +foo, etc) and it would already be presentable.
>>> >> Sooooo
>>> >> simple.
>>> >>
>>> >> My basic thesis: it's not content, it's metadata. while the html
>>> >> microformat folks can get away with it, it seems very out of place
>>> >> here.
>>> >>
>>> >> (I admit I am not able to write AS2 just from memory)
>>> >>
>>> >> {
>>> >>   "content": "Hello @foo",
>>> >>   "mentions": [{
>>> >>     "type": "person",
>>> >>     "url": "http://example.com/foo
>>> >>     "displayName": "Foo Bar"
>>> >>     "username": "foo",
>>> >>     "mentionedAt": [6, 4]
>>> >>   }]
>>> >> }
>>> >>
>>> >> I can then turn that into "Hello <a href='http://example.com/foo'>Foo
>>> >> Bar</a>" or "Hello @<a href='http://example.com/foo'>foo</a>" or
>>> >> "Hello +<a
>>> >> href='http://example.com/foo'>foo</a>" or whatever. Conversely, if it
>>> >> is
>>> >> html in the content, the substring would be the entire anchor tag,
>>> >> maybe. It
>>> >> would be very obvious that it would always indicate the position in
>>> >> the
>>> >> content before any processing is done.
>>> >>
>>> >> On Wed, Dec 3, 2014 at 2:14 PM, Matthew Marum
>>> >> <vp-projects@opensocial.org>
>>> >> wrote:
>>> >>>
>>> >>> The use of @[id|label].
>>> >>>
>>> >>> Matt
>>> >>>
>>> >>> On 12/3/14, 12:48 PM, "James M Snell" <jasnell@gmail.com> wrote:
>>> >>>
>>> >>> >On Wed, Dec 3, 2014 at 9:25 AM, Matthew Marum
>>> >>> ><vp-projects@opensocial.org> wrote:
>>> >>> >[snip]
>>> >>> >>
>>> >>> >> "@[Users:seed_paul_id:Paul] can you please help with this
>>> >>> >> opportunity?"
>>> >>> >>
>>> >>> >>
>>> >>> >> The first two parts form a unique identifier within a Sugar
>>> >>> >> instance
>>> >>> >> and
>>> >>> >> the final part is the display label.  Frankly, I’m not sure why we
>>> >>> >> wouldn’t use the precedent that Twitter API has established here
>>> >>> >> in
>>> >>> >>terms
>>> >>> >> of syntax.  I’ll leave any potential legal concerns to the
>>> >>> >> lawyers.
>>> >>> >>
>>> >>> >
>>> >>> >Which syntax specifically from the Twitter API?
>>> >>> >
>>> >>> >- James
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Ben Werdmuller
>>> > CEO & co-founder, Known
>>> > withknown.com | werd.io
>>> > +1 (312) 488-9373
>>> >
>>> > Known, Inc | 421 Bryant St | San Francisco, CA 94107
>>
>>
>>
>>
>> --
>> Ben Werdmuller
>> CEO & co-founder, Known
>> withknown.com | werd.io
>> +1 (312) 488-9373
>>
>> Known, Inc | 421 Bryant St | San Francisco, CA 94107
>
>

Received on Friday, 5 December 2014 17:48:53 UTC