Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] Notes for Higgins dev call - June 10, 2010

Notes for Higgins dev call – June 10, 2010

 

 

Attendees

 

                    Valery Kokhan - Azigo Ukraine

                    Mike McIntosh - Azigo

                    Mary Ruddy - Meristic

                    Drummond Reed - Cordance

                    Paul Trevithick - Azigo

                    Hank Mauldin - Cisco

                    Alexander  Yuhimenko

                    Sergey Lyakhov

                    Joseph Boyle

 

LOGISTICS:

 

                    Time: noon Eastern (16:00 UTC) U.S.

                    Dial-in: 1-201-793-9022 passcode 7990866#

 

AGENDA

 

(Discussion of wiki updates)

 

1) [Paul] HIGGINS 1.1 RELEASE PLANNING

 

                    Project plan [1] is this aligned with project metadata?

                    Higgins 1.1 release milestone plan [2] - walk through each solution and discuss

 

                    [Paul]  I updated the menu.  On the home page for Higgins, I got rid of our own custom plan.  It now takes you to the project plan page.  For Higgins 1.1,  I projected out the dates and created a new M9.  There is a link for each milestone.  I’m planning on removing the dates from the individual  wiki subpages to remove redundancy.  I’ve updated the description at the top.  I will add a link for the plan for 2.0 here.  Can only have one formal plan at a time.

                    [Paul] On the Higgins 2.0 plan (temporary wiki) I’ve created 4 subpages for sub milestones. There isn’t much detail there yet, but it is the genesis of the planning.  Maybe by tomorrow the wiki pages links will be fixed.

                    [Paul] Mary this is the official eclipse format.  Has the same problem that when you go there you are lost as the links are for Eclipse overall rather than for the Higgins project.

                    [Paul] I think is it far more important for us to have a single plan that we update in the official format.  So we don’t have discrepancies between various plan versions.

                    [Paul] Dates for 2.0 are just estimates for now.

                    [Paul] According to this plan we are working on 1.1M8.  The only items not done are more formatting enhancements for the down load page, assigned to Valery.  Is that still a part of the plan for next week, or should that be moved to another milestone?

                    [Valery] This is actually done. I believe it is done.

                    [Paul] There is also an item for Mary

                    [Mary] It is not large. I just need to get around to it. I’m not traveling for the rest of the week.

                    [Mike] 290669 is finished.  334… implement new build result pages will be done this week.

                    [Paul] We should focus on taking the items that are part of the 1.1 wiki pages and slotting them into milestone M9.  Right now there is nothing there as it is a brand new milestone. Alex, you were mentioning the card sync item.

                    [Alex] Yes.

                    [Paul] For milestone  M9, I could create a copy of the 1.1 page, all its sections, because there is no place to take notes on what you just said.

                    [Paul] Hit refresh, there is now a section for each solution on the M9 pages. Alex, are you saying that for 1.1M9 we should fix the card sync deployment instructions?

                    [Alex] Yes.

                    [Paul] OK. I have added an item for that.  So we now have a template for deciding what we will do for M9.

                    [Mike] I will do this offline before next week’s call.

                    [Paul] The 1.1 page is really a list of question to ask for 1.1. Next task is to have a list of bugzilla tickets.

 

2) [Paul] IDAS INTERFACE CHANGES FOR H2.0

               

                    Remove IHasAttributes on IAttributes (no harm in doing this for Higgins 1.1 as well)

                    Sub-contexts: what is our plan - are we going to implement sub-contexts using NG4Jena?

                    Graph traversal: which are we going to implement?

o   Walk a link to an entity in a different context and you get back the UDI or

o   Walk a link to any entity and get back either the real thing or a lazily loaded proxy

o   Some other idea

                    Other changes?

 

                    [Paul] Is Sergey on the phone.?

                    [Sergey] Yes.

                    [Paul] Was trying to make a list all in one place. On the Higgins 2.0 page, were there any items that I missed?

                    [Paul] At the bottom of the page is a building blocks section.  One is IDAS interface changes.  I wanted to first make a list.  The first item is removing iHasAttributes in iAttibutes.  I thought we had agreed on making that change. I want to go ahead and get it done with. I don’t think anything uses it.

                    [Sergey] I will remove.

                    [Paul] Should it be 1.1M8 or M9?

                    [Sergey] I would prefer  1.1M9.

                    [Paul] I will update that now.  Hit refresh.

                    [Paul] Subcontexts.  If this is going to be a huge project, we should reconsider doing it and just go with putting metadata like entities in the main graph.  On the other hand, if you feel that … I would like to do it… from the email last week. It looked like there were a lot of problems.  I want to understand.

                    [Sergey] Yes, we can implement it, but in my opinion, If we need to put meta data…

                    [Valery] Actually Paul, other approaches could have same problem. 

                    [Paul] So what you are saying is don’t bother with subcontexts, just have a meta data convention.

                    [Valery] Yes.

                    [Paul] So, the RDF community is using named graphs, but the named graph for the JENA implementation is so buggy and problematic that since I think we will need to move to another system anyway, if this isn’t fairly easy to do and will be buggy, it is not such a good idea.  So basically we aren’t doing it. So we will just develop our own conventions and change our client code to ignore or find those things… Mike, are we in agreement on all this?

                    [Mike] Yes.

                    [Sergey] I would prefer to not put this code in the client code.

                    [Paul] So you would change the IdAS interface so that the client of IdAS can say, give me the attributes about an attribute? 

                    [Serge] It is not exactly the same interface we just deleted.

                    [Paul] So we need a proposal for what we do.

                    [Valery] Let me make a proposal with Sergey. Then we can discuss.

                    [Paul] So stop work on subcontexts, and work on a design.

                    [Paul] The next topic is graph transversal.  So we can walk a graph within a contest or a logical graph that spans contexts.  My preference has always been that it would be nice if the client didn’t have to always be aware of context boundaries.

                    [Paul] What I was thinking is that it would throw an exception if it couldn’t get access.  It would simplify the client code from having to text every time.  What do you think?

                    [Mike] Is it any more trouble to test, then to attempt and have an exception handler?  It doesn’t seem like it is any more or less code.

                    [Paul] I haven’t looked at info grid.  It is the only other thing I know of that handles this to see how it handles this.  

                    [Paul] This seems like an area where we need a design and discussion. It reminds me of a third item.  Updating the model interfaces and hiding the model context. Behind those interfaces.

                    [Sergey] I’m pretty sure that is the way to go.

                    [Paul] These are things that we want to get done fairly soon.

                    [Mike] If the API can handle the exception locally, without messing up the client code, I’m all for it.  Just need to figure out how to make it work.

 

3) [Paul] XDI HARMONIZATION (new call at 1pm Eastern)

 

                    Discuss the idea of having weekly 30 minute calls immediately after the regular Higgins call that ends at 1pm Eastern.

                    The idea is to work on harmonization between the Higgins flavor of XDI and a new flavor now under development by the XDI community.

                    Each week we'd try to chip away.

 

                    [Paul]  The last time, I talked to Drummond about this issue,  about the difference between Higgins graph model and XDI. I’m  developing some new ideas.  And there is some interest. People beyond Higgins are looking to use XDI in the pure sense, and since we are not really (fully)interoperable with XDI, it creates an issue.  It is not an immediate problem, but Markus is developing his own XDI data store, and other commercial companies  are exploring developing XDI data stores. The idea would be to allow our active client to read from a Higgins data store and other non Higgins based data stores. In other words, have the integration happen at a client.  And that only occurs of we are all using the same messages.  We are 80% or maybe 50% compatible. The thought is that we could have a conversion every week for 30 minutes.  I need to create a wiki page with all these issues.  So that in a few minutes we can talk about it. 

                    [Paul] Mary I’ m done (with the topics for the regular Higgins call).

                    [Paul]The XDI call is on the same call bridge. It is a continuation of the Higgins call with a fixed topic and fixed time.

                    [End basic Higgins call]

 

                    [Paul] Resuming with the XDI specific call.

                    This is the call with the XDI topic.  Have just created this wiki page [3] and hope it represents the latest thinking.

                    [Paul] Let’s go through the wiki page. It is the result of conversations in Munich.

                    [Paul] Higgins speaks an XDI dialect. Hope to over time adjust the Higgins code so that it is conformant with PDX (which will be an XDI dialect that is maintained at XDI .org.)

                    [Drummond] There is pure XDI. PDX is just a dialect.  Joe is that clear?

                    [Joe] Yes.

                    [Paul] The next item refers to CDM/PDM.  Taken together they define the types of graphs that will be found in production Higgins space systems.

                    [Drummond] I suggest the term Higgins RDF graph.

                    [Paul] Higgins is usually more general that RDF, and occasionally more restrictive.  We can also use XDI’s for URI’s example.

                    [Paul] We have 4 kinds of issues to resolve. So now we can take a look at them.

                    [Paul] Our base data model is something we call CDM.  It doesn’t allow blank nodes, and we don’t necessarily use RDF technology to implement CDM.  It isn’t a perfect layering. The persona data model  is not only a vocabulary, it also restricts the identifiers.  The persona model can always differentiate between absolute and relative.

                    [Drummond] We should mark each issue, by category as we go through them.

                    [Paul] I’ve updated the new wiki page during the discussion.

                    [Paul] Global URI’s, if resolvable, resolve to exactly one description. 

                    [Drummond] That is technically correct, but multiple versions may be technical versions for the same thing.

                   

                    [Paul] CDM will house multiple values, XDI does not…

                    [Drummond] Subcontext in XDI means a nested graph, not a named graph…..

                    [Paul] I’ve  updated the wiki pages as we’ve talked.  We can continue next week. 

 

[1] http://www.eclipse.org/higgins/projectplan.php

[2] http://wiki.eclipse.org/Higgins_1.1

[3] http://wiki.eclipse.org/Higgins_XDI_Harmonization

 

 


Back to the top