Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] Notes from September 18 Higgins developers call
Attendees
* Tom Doman - Novell
* Andy Hodgkinson - Novell
* David Kuehr-Mclaren - IBM
* Dale Olds - Novell
* Ernst Plassmann - IBM
* Drummond Reed - Cordance
* Bruce Rich - IBM
* Mary Ruddy - Meristic/SocialPhysics
* Markus Sabedello - Parity
* Jim Sermersheim - Novell
* Paul Trevithick - Parity/SocialPhysics
* Brian Walker - Parity
* Hank Mauldin - Cisco
September 18th Higgins developers call. Time: noon EDT (1700 London; 1800 Vienna, Paris, Berlin)
Dial-in: 1-866-362-7064 / 892048#

Agenda

1. [Brian] We are still working on 1.1M4.  
  • [Brian] Update on M4.  Sent a note out earlier this week trying to finish-up work on M4. Mike is diligently working on that. Wanted to give people time for regression testing and bug filing.  So moved it out to next Friday, 26th September.  Will continue to communicate over email.
  • [David] Will there be an informal build for testing?
  • [Brian] Will arrange, and will communicate when.
  • [Mary] Several more people have just joined the call. We have been starting at 12:05 so that people who have standing calls before this call have time to get on the Higgins call.  Do we need to start later than 12:05?
  • [Drummond] This week was a packed agenda. I try to have discipline on ending the call on time.
  • [Mary] So we will continue to start the call at 5 after. 

2. [Mary] Next Higgins F2F
  • Decided: Boston is the next location  (Austin was runner up.) 
  • http://www.doodle.ch/participation.html?pollId=gxzpfiuzdg4kveha - Poll  on approximate dates.  
  • [Mary]  I strongly encourage folks to enter their preferences on the doodle…. Need t have a solid decision by next week’s call.  Need Mike’s input as he is responsible for key components.
  • [Drummond] Need to make travel arrangements.
  • [Mary] The next topic is entity identifiers. Paul, it is all yours.

3. [Paul] 0..n entity identifiers; mutability
  • [Drummond] How much pain may be caused by a relatively likely context?
  • [Tom] It doesn’t matter if LDAP has an immutable CP or not.   Need to be able to expose it,  and application can check if they are immutable or not, not really knowing what the back ends is capable of.
  • [David] There is also guaranteed unique and maybe unique. A guId is guaranteed unique.
  • [Drummond] Just a pure suggestion, living and breathing identifiers at the XRI TC,  it would get a lot simpler if an identifier is unique in a context. If we stick with that, it is entirely up to the CP. If not unique in a context is not an identifier.
  • [David] That puts a burden on the CP even if the store does not.  LDAP doesn’t enforce that.  Would need to write logic to constantly check if it is unique.
  • [Drummond] That seems better than to force all applications using IdAS to….
  • [Paul] Actually I don’t think David is saying that. I think he is saying that it needs to be inspectable. That is a radical new requirement. That is for entityId’s that aren’t guaranteed to be unique in the context.
  • [Jim] How does a CP even surface that?
  • [Paul] I have no idea.
  • [David] I’m struggling with that…
  • [Jim ] We were talking about mutability.  Now we are talking about uniqueness. Just because have uniqueness, doesn’t necessary mean have mutability.
  • [Drummond] Suggest we partition that into a separate conversation.
  • ….
  • [Paul] Can I walk through this one proposal?  Then we will have something concrete to throw arrows at.
  • [Paul] Hit refresh. I added a new change.  I’m at proposed changes 1.1. Number 2, I added a new predefined Higgins synonym type.  For developers who wish… then can tag attributes as being synonyms. For instance…..if a mobile phone…
  • [Paul] By using the potential for multiple inheritance, it is not easy.  It makes it hard to use existing attribute definitions developed by other ontologies, but you can wrap that.
  • [Paul] Next, number one deals with….So lets look at a concrete example using this proposed straw man. There is a context with two entities.  The developer has chosen to use soc that is unique in the context. The developer has chosen the option of repeating the unique entityId as a developer defined attribute… Two of the attributes are tagged as being synonyms.  Shoe size is not, so shoe size is not an identifier.  I combined Mike and Tony’s idea.  In this context can search by …. and all get the same entity.  The rest is some specifics.  So if you call get synonyms get two attributes, mobile and soc.
  • [Jim] So what can you do with the synonyms?   Are we also proposing can pass synonyms entity also?
  • [Paul] – I haven’t come to that, but that would be a convenient.
  • [Drummond] That is not a search. That is a direct mapping, as long as those definitions hold.
  • [Paul] Maybe should add getEntity by synonym…..
  • [Jim]…
  • [Drummond] Should be able to pass get entity method either entity or synonym.  Should get it.
  • [Drummond] What Paul is saying is there is value from distinguishing between, but both should work. There are several properties of canonical.  What we are saying is that canonical can be mutable.  In that case it is no different from a synonym,
  • ….
  • [Paul] There are responsibilities that IdAS has to dereference if you give it the canonical entityId.  I have not proposed here that the synonyms are first class.  When we move to deep rather than shallow, I think you are putting too much burden on IdAS to take any of the synonyms and be able to reference them.
  • [Hank] Isn’t the point of the synonym to be able to get the entityId?
  • [Drummond]  It all falls down if the canonical id is mutable.
  • [Paul] Yes, when people want canonical mutable id’s then all bets are off that can associate, etc. reliably.
  • [Drummond] It becomes an order of magnitude harder.  It isn’t that it isn’t doable.
  • ……
  • [Drummond] Paul, on your proposal that is here, what if entity is 0-1 and synonyms are 0-N that we make the entityId immutable.
  • [Paul] I think that makes sense. But I don’t know if people think this is too much of a burden.  If we do introduce…. The general ability to correlate .. all goes away. It just becomes a flat database.
  • [Jim] In fact that is not shutting out any CP, just saying if can’t provide, a mutable entityId is zero.
  • [Drummond] If you can’t support immutable entityId’s, then you reference an entity the same way, but the identity you pass in is a synonym. 
  • [Paul] So you would say has entityId.   Does anyone disagree?
  • [David] I think Tony will disagree.
  • [Jim] getEntityId passing no arguments, I will get back some entityId value that I can use to locate the entity. I’m not guaranteed mutability.  I can also add a Boolean, get canonicalId.  That is your test.  If get canonical returns nothing, it doesn’t have one.…
  • You might get … Need to return the list, might get entityId’s (the whole list.)
  • …..
  • Maybe…
  • [Paul] I vote for get canonical single and get canonical plural,…That is half way.
  • [Paul] A couple of years ago….. so we just punted. Now we have created a distinction between an attribute and an attribute that is tagged in a certain way…
  • [Jim] I think this new tag is really identifying all the attributes that the context claims are unique.  That in itself has some interesting benefits…  I think that discussion can be had outside the scope of this one.
  • [Hank] Is it a value pair?
  • [Paul] Great question. I would argue it should be pairs, and it would say URI for attribute type. Mobile would be paired with phone number. In answer to your question about the canonical one, I think we have to reintroduce an entityId attribute. 
  • [David] I think the id would be the quId and then the value. 
  • [Jim] Are we investigating what the type is that is returned?  Is it strings or is there structure around it? If it is just strings, the CP can build up the strings any way it needs to.  So in Paul’s use case you would need to build strings that are pairs. But in another CP you might have synonyms. If we actually propose a specific type, name value pair, I don’t know if we introduce hardship for CP writers. Or over complicating things.
  • [Drummond] I want to clarify. So the CP could be indexing the data in ways that may not have a corresponding attribute type to pair with the index values.
  • [Paul] Yes.  I also head that people are saying that they don’t want to require that these be exposed as attributes.  If we all agree on requirement that these attributes not be exposed, than my proposal won’t work.
  • [Jim] If I concoct 5 synonymous attributes, they would all want to have different types.
  • [Drummond] Couldn’t I produce three that are just…..
  • [Jim] Yes, I could.
  • [Hank] ….
  • [Drummond] Could have indexing value not exposed as attributes… And also want to enable both.  If entityId’s required list of values and type, can return type of attribute if it is an attribute, if not, if just an internal indexing value, just include that in list.
  • [Hank] That seems OK.  That puts the CP on the hook to make sure they are unique enough to do that.
  • [Jim] – I don’t like this. It sounds like we are proscribing a specific type for an entityId that is a named value pair for those not exposed as an attribute.
  • [Paul] What I heard is we want to support entityId's that are supported as an attribute for now…
  • [Jim] The topic has more…  when they get back the entityId’s’, those values have to be paired with the types they are associated with, especially in the case they are attributes.  Your employee id attribute provider might be the same as your soc.  So the value needs to be paired with their types.  So do we proscribe that every entityId is paired with a type or do we just say that CP’s need to do the right thing and pair the id with its type if it needs it to make it unique.
  • [Hank]  I heard it differently. 
  • [Drummond] To clarify, if jim is an attribute, get back a URI pair for internal context identifier and 1234jim.
  • [Jim] Today I can go to a context and say get me entity Jim.  Tomorrow I will need to type out a URI. 
  • …..
  • [Jim] The initial question is do these values need to come back as types values or must the value itself… You could have cross type, non uniqueness…
  • [Drummond] What is required by getEntityId is all are unique indexes in that context.  Multi-part keys are a separate discussion.  There is not consensus if we need support for multi-part keys…and how to provide them.  So Jim, if every value on that list is an entityId in the context and the context is with it … then don’t need to add the type to scope it as unique.
  • [Jim] So say a company just bought a company.  Both have assigned 5 digit employee id numbers.  So they bring in the old employees and they retain old employee numbers and assign new a number called employeeId. The person rolling this out wants to use employeeId as entityId, but can’t because of the danger of there being cross attribute non uniqueness.
  • [Paul] Almost out of time.  I think, as usual this discussion has brought up new requirements.  I think I have outlined another proposed solution that we can go though next time or on the list. I think I can see a variation of what we have here. We are all agreeing that we have some identifiers that don’t have to show up as attributes.  If it is important enough to add that new requirement.
  • [Hank] For all of these id’s that if you have another key you don’t expose as an attribute, are you going to declare it as a synonym?  What does it mean to have attributes that aren’t exposed or attributes…  I get having multiple keys. 
  • [Paul] Attributes that can be marked as identifiers. And other entityId’s that don’t show up as attributes, I think we need to return those as pairs. I don’t think soc is a multi-part key.
  • [Drummond] If is ssn and is ssn…  The context needs to know which index….
  • [Paul] The canonical one is a UDI. Only one more step needed to support multi-part keys: allow the piece to be a complex attribute.
  • [Jim] Need to support that my entity is jim or james and I can look it up without other stuff..
  • [Drummond] Good point.
  • [Paul] Out of time.  We will keep grinding forward on the list.
  • [David] Even if we get a list back of attributes, applications will still need to know which are mutable, writable.
  • [Drummond] Which are unique that can be used untyped. If the typing gives you the information you need, than every application can do what it needs.
  • end


Brian Walker
=brian.walker
VP of Engineering
Parity Communications Inc
cell: 781-801-0254



Back to the top