Open Social Data Spec, People, and how to find people in the container network

[ddumont]

I'm looking at writing a few gadgets that have to do with email. I
want to fire a selection event when someone selects an email from
their inbox.

I have the email address of the person who sent it, but there don't
seem to be any apis to ask the container for person information given
an email address.
How is one expected to deal with figuring out if a person is actually
in-network within this container? And what if they are out-of-
network?

Is there an alias for unknown people, like @unknown where you can
provide the email address so that gadgets that primarily key off of
this selection can still offer the ability to send messages to them?
Maybe display a generic silhouette for their profile picture?

[Mark W.]

If the target is gmail, then you should look at the APIs for the contextual gadgets. These are non-standard extensions that google has put in place. If you've got a different email provider, then they'll need to support the opensocial APIs. You can use the get person and then include the fields parameter, this would include email.

http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Gadget.xml#osapi.people

[ddumont]

There lies the rub:
>>>> snip
2.1.1.1.1 Get Person Request Parameters

A request for a Person object MUST support the Standard-Request-
Parameters and the following additional parameters:

Name Type Description
userId User-Id User ID of person to retrieve. Defaults to "@me", which
MUST return the currently logged in user. Note that the userId
parameter is not applicable in the REST protocol, as the user is
identified in the REST-URI-FRAGMENT.
fields Array<String> An array of Person field names. For standard
values, see the Person object.
escapeType Escape-Type Specifies the type of escaping to use on any
AppData values included in the response. Defaults to "htmlEscape".
<<<< snip

All I have is the email address of the sender. I have no idea if they
are in-network or out-of-network.
I don't have the required userId to send to this call. :(
It looks like the fields that you want to include are not to specify
information you have ( and thus search ) but to limit the response to
contain only the fields that you are interested in.

I'm also concerned about no mention in the spec to be able to identify
an unknown out-of-network person, but still allow this identity to be
used by other gadgets.
I'm imagining something like a google talk gadget that monitors people
selection and will let you start a chat with the selected person.

If you get an email from a person out-of-network, and all you have is
an email address, I would be able to query the api for a Person object
given that username. then perhaps if none is found, a standard
@unknown with the appropriate *known* info (email address) is filled
in as appropriate. That way the gtalk gadget can show a "Invite to
Google Talk" action instead of chat.

> parameter, this would include email.http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Gadget...

[rbaxter85]

What we need is a search API...
Dan, can you write up an issue for this? Don't make it specific to
people though, it should be a search API for all OpenSocial data
types.

[ddumont]

Done: http://code.google.com/p/opensocial-resources/issues/detail?id=1206

[Mark W.]

Agree, a search API would help here. 

Another interesting option is to provide a web finger endpoint for OpenSocial containers. In the case of Jive, and I suspect other containers e.g. connections, we could add a service that supports web finger that would return part of the public profile in OpenSocial form. 

This probably does not make much sense to have in the JavaScript API, or maybe even the REST API, but it could go in the discovery section. 

Dan, et al, what do you think of this idea? 

[Niels van Dijk]

Hi,

Would it make sense to not write something new, but implement something
like e.g. OpenSearch here? ( I think this was actually proposed earlier
already)

Cheers,
Niels

> --
> You received this message because you are subscribed to the Google
> Groups "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/KCg0eLuKMukJ.
> To post to this group, send email to
> opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

[Andrew Davis]

OpenSearch is not a spec on how to search data like this.. but a way to describe existing search endpoints and how to display the results in a browser/UI.

So yes opensearch could describe an opensearch endpoint.. but we still have to design the search API for people to solve this problem

--Andrew

[Mark W.]

And I don't think this is an either/or approach. I believe we need the search API b/c that can be used from gadgets. But something like web finger may be more useful for server to server integration.

[drobin]

I like the suggestion of webfinger.

Generic search APIs can become very complicated and perhaps we don't need that level of capability.

Not trying to split hairs, but something more like a 'find' in a 'confined' space feels more like what we need -
for example we want to "find" a person that has a particular email address.

[Igor Belakovskiy]

So Dan, for your purposes, would something generic that lets you
specify a query string and a map of optional parameters work? (See
contrived example below)

var query="";
var paramMap= {"email":"*gmail.com", "type":"person", "firstName": "Dan"};

container.search(query, paramMap); // returns all people named dan who
have gmail addresses.

This dovetails nicely with the parameter specification for OpenSearch
(http://www.opensearch.org/Specifications/OpenSearch/Extensions/Parameter/1.0),
which will allow the container to expose this functionality to others.

On the implementation side, the container could either implement exact
match or full text seach.

I think supporting webfinger is also a good idea.

> --
> You received this message because you are subscribed to the Google Groups
> "OpenSocial and Gadgets Specification Discussion" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/68p8guK4dksJ.

[Craig McClanahan]

On Wed, Aug 24, 2011 at 11:03 AM, ddumont <ddu...@us.ibm.com> wrote:

Done: http://code.google.com/p/opensocial-resources/issues/detail?id=1206

Added this comment to the ticket that might be of interest:

One option to consider is adopting the SQL-like query grammer from CMIS <http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html#_Toc243905420> for this purpose.  This will become even more compelling if CMIS is adopted as the standard OpenSocial API for documents and folders, because developers would not have to learn new concepts to search people/groups/etc. versus documents and folders.

Craig

[Niels van Dijk]

Hi

Webfinger is interesting indeed, but would we not need webGroupFinger also?

Cheers,
Niels

[ddumont]

This would be useful as a gadget->container API for finding people,
and would fulfill my usecase perfectly. As Andrew said though,
there's no REST API support here for that to build on top of.

There should probably also be some discussion on what to do when you
get more than one, or ambiguous results when doing a search.
Perhaps you search for a person by email address as a result of a live-
text selection. You want to publish selection with the
OpenSocial.Person you've found. But for some reason, you get 2
results... or no results.

It would be interesting to be able to still set selection to a Person
object with id == "@unknown" with known information filled out.

On Aug 30, 4:26 pm, Igor Belakovskiy <b...@alum.mit.edu> wrote:
> So Dan, for your purposes, would something generic that lets you
> specify a query string and a map of optional parameters work? (See
> contrived example below)
>
> var query="";
> var paramMap= {"email":"*gmail.com", "type":"person", "firstName": "Dan"};
>
> container.search(query, paramMap); // returns all people named dan who
> have gmail addresses.
>
> This dovetails nicely with the parameter specification for OpenSearch

> (http://www.opensearch.org/Specifications/OpenSearch/Extensions/Parame...),

> which will allow the container to expose this functionality to others.
>
> On the implementation side, the container could either implement exact
> match or full text seach.
>
> I think supporting webfinger is also a good idea.
>
>
>
>
>
>
>
> On Tue, Aug 30, 2011 at 3:41 PM, drobin <drobin1...@gmail.com> wrote:
> > I like the suggestion of webfinger.
>
> > Generic search APIs can become very complicated and perhaps we don't need
> > that level of capability.
>
> > Not trying to split hairs, but something more like a 'find' in a 'confined'
> > space feels more like what we need -
> > for example we want to "find" a person that has a particular email address.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "OpenSocial and Gadgets Specification Discussion" group.
> > To view this discussion on the web visit

> >https://groups.google.com/d/msg/opensocial-and-gadgets-spec/-/68p8guK....

[rbaxter85]

I don't really like the web finger solution because its specific to
people. I would like to see a generic search solution so I can not
only search for people, but for activities, messages, etc.

[rbaxter85]

Dan this was brought up on the call today and we have general support
on adding a search API to the spec. Let's start to work on a proposal
for this. Maybe we can bring in Igor the search guru to help us out.

[ddumont]

Excellent!

[Mark W.]

OK... Let's take WebFinger off the table in terms of this discussion. We should start another one just on that topic.

In terms of search, I'd think we'd want a new service that returns an opensocial collection if there's more than one. 

[rbaxter85]

We had a discussion on this topic today. We started to brainstorm on
things like OpenSearch. We were also looking at the examples in
section 6.2.7 of the Core API Server spec.
http://opensocial-resources.googlecode.com/svn/spec/2.0/Core-API-Server.xml#rfc.section.6.2.7

We were wondering if we could expand on that syntax to form some kind
of search API.

[Laurent-Walter Goix]

the filtering parameters may be a good starting point but i am
wondering on how to query for "people" in general (not yet my
friends). what would be the request URI for that? should the "@all" be
used in case i want to search over the overall network?

e.g. /rest/people/@me/@all?
fields=name,id,gender&filterBy=name&filterOp=startsWith&filterValue=John

this could apply to any Service probably in the same way, e.g. to
query for activities or other.

in this case it may be already supported but could be emphasized in
the spec through a dedicated section.

probably an opensearch descriptor could easily be built as well
(although the response should probably be formatted differently,e.g.
as atom)

walter

On Sep 10, 4:30 am, rbaxter85 <rbaxte...@gmail.com> wrote:
> We had a discussion on this topic today.  We started to brainstorm on
> things like OpenSearch.  We were also looking at the examples in

> section 6.2.7 of the Core API Server spec.http://opensocial-resources.googlecode.com/svn/spec/2.0/Core-API-Serv...

>
> We were wondering if we could expand on that syntax to form some kind
> ofsearchAPI.
>
> On Sep 9, 12:25 pm, "Mark W." <weitzelm.w...@gmail.com> wrote:
>
>
>
>
>
>
>
> > OK... Let's take WebFinger off the table in terms of this discussion. We
> > should start another one just on that topic.
>

> > In terms ofsearch, I'd think we'd want a new service that returns an

[Mark W.]

I'd rather see us do a proper search api than try to hack a syntax on each service endpoint.