Re: Federated/Distributed @mentions

On 5 Dec 2014 17:48, "James M Snell" <jasnell@gmail.com> wrote:
>
> 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?

The content the user gives you can be in any format you want - its a UI
issue and out of scope. The data you syndicate/pass through the API should
be AS2 JSON with embedded HTML with optional inline metadata.

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

But this is the important bit - how we interoperability convey that data.

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

I don't see any plain text content in AS2 so it's irrelevant.

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

Sure. I Prefer RDFA over microdata because it's more concise and a better
model, but inline metadata markup in our content makes sense as an optional
feature.

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

LD being the whole syntax and transport model...

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

The only content you need to /examine/ is that coming in through your own
UI. That is a matter for you and you alone.

For everything else, as:tag/mention should be what you need.

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