Table of Contents

...

•  Former user (Deleted): develop a proof-of-concept bot to recognize CDS entity references and respond with in-line data about the security.
  •  All: contact Former user (Deleted) if you're interested in working on a custom renderer for the CDS data returned by the bot
•  Former user (Deleted): will work with Symphony LLC's Product Marketing team to create proposed "marketing" material describing the WG's activity in business-friendly terms.
•  Johan Sandersson: update list of financial objects to into separate namespaces (e.g. fin, obj, idn)
•  Aaron WilliamsonAaron Williamson: reach out to BNY Mellon to line up presentation from API developer working with ISO 20022

...

Action items

•  Former user (Deleted): add your comments related to roles and historical attributes to the contact object model page in Confluence.
•  Former user (Deleted): move com.symphony definitions into "proposed standards" or "working drafts" section as appropriate. 
•  Johan Sandersson or Aaron Williamson: add Jim Walker from BNY Mellon to next meeting's agenda.

Meeting notes

Johan Sandersson: Slava, do you want to give a 1-minute bio and DB’s interest?

Slava Kryukov: I’m working on the interop solution and Plexus, which we intend to open source to the Foundation and integrate it into Symphony chat. So as part of that, is standardization around taxonomy of the data and actions. I’ve spoken briefly at the annual members meeting and one of the suggestions I raised is to add the actions taxonomy into this working group. Which is something we can come back to, but to wrap up, my interest in the group is around data taxonomy that can be used for interop.

Johan Sandersson: Thank you. So running through action items from previous meetings. Frank, do you want to give an update on your CDS project?

Frank Tarsillo: I’m still working on the upgrade to 1.46 on SJC. That’s going through a big overhaul that’s taking me a lot longer than I thought, but once I’ve finished that we’ll get back to the CDS implementation.

Johan Sandersson: Did you catch up with Hershal about what a CDS object is versus the attributes, e.g. the various identifiers.

Hershal Shah: Frank just got back today, and happy to get back to that, but don’t want to disrupt the agenda.

Johan Sandersson: PHT, marketing material?

Paul Teyssier: Still in progress, but should be moving faster now.

Johan Sandersson: On my end, I started on the namespace work, but got confused a bit so I added an agenda item. In the notes, there’s some conflicting information, so that’s still outstanding. Aaron?

Aaron Williamson: I reached out to the developer at BNY Mellon who designed their APIs to conform to ISO 20022. The developer has left BNY since our last conversation but his supervisor, Jim Walker, offered to talk to the group. He’ll be joining the next meeting on July 27^th.

Johan Sandersson: Any other agenda items people would like to add? So we can go straight into the agenda. As Paul and I took over from Bruce, there was a lot of documentation in the wiki that we thought we should try to structure a bit. So those who have added things in the past, you may find those in “Archived Resources.” We then focused on three pieces: standards (that we’ve voted on and approved), proposed standards that have yet to come up for a vote, and then most work will be done in working drafts, where we try to put together new standards for financial objects. Those should still be fairly organized. We don’t want to make it too cumbersome to add things, we have working group documents, which should be sort of free form so you can add things easily for discussion. Is that all clear? Do you have any suggestions for revisions? Slava, I know you’ve thought a lot about this internally with Autobahn. How do you communicate standards?

Slava Kryukov: I wouldn’t say we’re at the forefront of standardization, because we have competing standards internally. But I like the approach and it’s very close to the way we’ve begun working internally, so it makes perfect sense to me.

Johan Sandersson: Good. Paul, any additional comments?

Paul Teyssier: I think you did a good summary and it sounds like the purpose of what we’re doing here is to pivot from an engineering focus to a more normative focus so we can help our organizations but also provide guidance to other organizations who might be considering creating and using objects. I think that’s quite important.

Johan Sandersson: The other thing we discussed was the namespace methodology. One standard defined already is what the LLC is already using. They might need an update, is that right Paul?

Paul Teyssier: Yeah, the commercial objects generated by Symphony move all the time. So if some are important to the group, we can update that. But the goal of this section was to show the thinking process and a couple of relatively easy ones. So I don’t know if it’s necessary to update them or keep them fresh since they’re internal, but if there’s interest from the group we could do that easily enough. For example, the user, userid, mention, are exactly the kind of thing being discussed for the contact object, so we might want to be clear there and define the relationship to contact.

Johan Sandersson: Frank, I would think that a link would be something that a lot of objects would contain, so if everyone’s using the link entity, you should be able to feel confident that Symphony and apps can parse that. So I think it makes sense, not to list everything various providers have as proprietary standards, but if we’re using them in other objects they should be here and updated.

Paul Teyssier: Yeah. I’d suggest just using this page to leave comments and make suggestions. We had a long debate when the page was written whether some objects were standards and some were internal. But if your org is planning to use one of these objects, let’s use that document to collaborate around how we’re using them.

Johan Sandersson: Why is com.symphony.link an entity and com.symphony.uri an attribute?

Paul Teyssier: Click on link. So it contains six attributes. Type and provider only have one instance now but could be extensible depending if others are interested in defining different types of links.

Johan Sandersson: Should we move com.symphony piece into proposed standards or working drafts?

Paul Teyssier: Yeah, we should. I can do that.

Johan Sandersson: Any further questions on namespaces? What we spoke about is what we are defining here as a group should live under org.symphony.oss. If we’re using something proprietary, you should most likely use something that defines it as your information. So at FactSet we’d say com.factset.security or something to make it clear that the object has been defined by FactSet and not the working group. And we did that change with some of Jeff’s Ipreo identifiers in the contact model. Does that make sense?

Paul Teyssier: And just so you know for contacts, the namespace we’d focus on most would be com.symphony.[?].fin.

Johan Sandersson: So maybe that’s what I was supposed to do here, was rather than calling this a generic object, I should change that to fin and sync up with Jeff about what he wants to call the contact object. Frank and Hershal, would you consider the CDS object a Foundation or a Markit object?

Frank Tarsillo: Since we’re the only producers of it, I would consider it… well, actually I’d consider it a Foundation object.

Paul Teyssier: Would it have com.markit attributes in it?

Frank Tarsillo: No, I think the codes are industry standards now.

Hershal Shah: That’s right. The key that defines the object should be a Foundation object that should be the industry standard.

Johan Sandersson: That’s fine. So nothing here is proprietary to Markit, even the CLIP ID? Could anyone else build their own CDS objects with their own CLIP ID?

Frank Tarsillo: The CLIP ID is generated by IHS Markit as a company because we currently own the data. But if that were to change I think the definition should stay the same. Are we defining namespaces according to where the definition comes from or according to the source of the data?

Paul Teyssier: I think we’re defining a namespace for both. I think there’s an implicit norm that subattributes indicate who is the owner of that entity or attribute. So it’s really a standard and we just need to define where we want to go.

Frank Tarsillo: So the namespace should define the source of the value as part of the namespace.

Paul Teyssier: Right, so if the FOS WG is the place where changes to the format and data and IDs can happen, it should be org.symphonyoss. If that’s another entity, it should be their namespace.

Frank Tarsillo: I hear that. So that means the current namespaces for CUSIP and ISIN should change?

Paul Teyssier: I think with those we could go both ways. Because they’re both standards, but yes they could change and the system should support that. So how would we namespace those consistently according to the principle I just articulated?

Aaron Williamson: Frank, if the CLIP ID wouldn’t be namespaced to Markit, when would you namespace something to an org besides SSF, Frank?

Frank Tarsillo: I would keep these things as standard entities that were not namespaced to a particular company, because they get acquired and things get confusing. Maybe they should be not attributes but entities, and then you can specify the source in an attribute.

Paul Teyssier: Yeah, I think it should be case-by-case, because we could end up with endlessly nested entities.

Frank Tarsillo: I understand that concern, I think it’s easier to articulate and reduce bloat by just defining the attribute if it’s in fact unique.

Johan Sandersson: Ok, let’s move on. Not the last word on that but we can take it case-by-case when we have proposals. Key item for today was to discuss Jeff @ Ipreo’s addition of a shared contact. I’ve had a look at it, I think it makes perfect sense. There were some comments from Bruce regarding how to use names, that first name last name was a Western convention. Anyone have thoughts or comments?

Paul Teyssier: My thought was, what is the relationship between contacts and mentions? Mention is clearly the same thing as Symphony user. And in the interest in keeping the object model as simple as possible, I’m leaning toward merging those with contact. You could go either way but I’m leary of breaking use cases that need that distinction.

Hershal Shah: One depends on the other and should be linked, but there should be some way to normalize that.

Paul Teyssier: So contact would be the superset and mention would be the subset?

Hershal Shah: Yes.

Paul Teyssier: So a subcontact would be a symphony user. I think that makes sense.

Hershal Shah: I would go as far as to say that you should be able to @-mention contacts. When you think of click-to-dial, you may want to reach someone who’s not on Symphony.

Paul Teyssier: That’s what I was saying. For these use cases, it might not be Symphony that knows your phone number but some other system. But I don’t know if you would @-mention a contact, you would use the Symphony chatroom to make a mention, and then another system would pick that mention up and take it from there. So you would use the contact underlying the mention, not @-mention the contact per se.

Hershal Shah: That makes sense, but I think of email – I can send a contact card, or I can hover over a contact record and see attributes, click the email address, etc. I wonder if we should anchor the mention as a contact object…

Paul Teyssier: The way it currently works is that when an @-mention is made, it can be augmented by another system, but the underlying data is just a simple mention object. You wouldn’t find an entire contact object in the data stream because it’s a big object and to handle it in a performant way you have to do caching and complicated lookups. So what happens in the stream is maybe a mini-contact but not the rich and heavy contact object.

Hershal Shah: That’s fair, I’d like to hear others’ thoughts.

Johan Sandersson: I think it’s an interesting thing. I was intrigued by the idea of sharing a contact and it automatically becoming an @-mention, but I can see why you wouldn’t necessarily want that to happen. In some cases you might want  to say you should talk to @bob or just you should talk to (contact) Bob.

Paul Teyssier: I think we need everyone in the room for that but I think we’ve made progress.

Johan Sandersson: There was some discussion on the contact role id and maybe also the contact info id, and I think what Bruce meant and what is relevant is that you could have multiple identities, even actively at one point. You could work for two companies or have two email addresses—I suppose it could just be extensible so you could list unlimited organizations if you’ve worked at several over the years. What Bruce was discussing was the difference between the persona and the individual. I don’t know if they’re necessarily separate as such. I think what Jeff was thinking about was the sharing of the data, so that one system can send an another consume it, and that it should therefore be able to see the whole history of an individual. Does anyone else have an opinion on whether you should only be able to send current information (or one persona), versus a historical person. I’m leaning toward the former, being able to send the complete history.

Paul Teyssier: I think that’s the beauty of having an extensible format. Systems can work with a subset so there’s no reason to limit it.

Hershal Shah: Ipreo owns a database called “Bigdough,” which tracks the history of contact information. I think it’s valuable to have extensible attributes. But I don’t think the “role” attribute makes sense in this context, since different organizations define roles totally differently.

Paul Teyssier: I agree, I think we should support a title field but I don’t think we can normalize this. You can’t assume that there’s a shared notion of roles across organizations.

Johan Sandersson: I agree.

Slava Kryukov: Question, what is the canonical ID with which Symphony identifies a user? How is it constructed and is it transferable?

Paul Teyssier: The Symphony ID is per-pod, so if you change organizations, you change IDs. In the future there could be something more permanent, but that’s how it works now. So there’s no collision.

Slava Kryukov: Just thinking about my use case, correlating particular individuals with an internal DB identity, and I’m thinking that if the identity of a person is pod-associated, I might lose that connection when they move. Well, I think that sounds reasonable.

Johan Sandersson: Hershal, I think you had some great comments on the role id and historical information, so if you have a few minutes to add your comments to the page, I think that would help the conversation move forward.

Johan Sandersson: I was pinged about this company GLEIF, which tries to standardize the identities of companies/organizations around the world. Definitely something we could all take a look at and see if we want to incorporate it.

Frank Tarsillo: We use GLEIF as a starting point for LEI information. It’s not perfect, but it gets you to the top level in a company hierarchy, but not necessarily to all the subcompanies. But it’s definitely good to look at and understand as a group.

Johan Sandersson: Anything else? We have the mailing list and Confluence, so let’s continue the conversation between meetings. Do we have multilateral chatrooms coming up Paul so we could move to that?

Paul Teyssier: No comment.

Attendees