Skip to main content
Jump to: navigation, search

Dereferencing Complex Values Backlog

Revision as of 02:25, 14 March 2008 by (Talk | contribs) (Questions/Observations)


This page describes a proposed change to the IdAP API and the IContext SPI. This page was created to support a discussion.


  • We change the IdAS API and the IContext SPI to return IEntity implementations
  • In other words, eliminate IComplexValue and replace it with IEntity


   IComplexAttrValue IAttribute.addComplexValue(URI dataType)
   IEntity IAttribute.addComplexValue(IEntity)
 or maybe:
   IEntity IAttribute.addEntityValue(IEntity)
 IComplexAttrValue <-- goes away



  • Would all of these 'complex attr values represented as IEntitys' have identifiers?
    • It seems like a good thing for cases where you want to share one across different identities. For example, my wife and I have the same postal address so it'd be nice to share the same complex attr val for that.
      • Hmm, people might see the utility in that and want something similar for simple attributes as well
  • I hate to admit it, but if we make attributes act just like entities, it makes a good case for calling things something more generic like Node or Element.


  • I agree. For example, in XDI, the value of an attribute can be a literal, a reference to another Entity, or a reference to the value of another Attribute (of that Entity or a different Entity). It seems IdAS should have the same options.
  • However, doesn't an Attribute whose value references another Entity become a Relation?
  • Lastly, RE Jim's terminology point, I agree this capability emphasizes using the most general term for nodes in the graph. That's why I favored the term Node. Interestingly, given that we already use Attribute, for the first time I could make sense of using Element. (I have always feared confusion with XML, but if we ended out using both Element and Attribute, at least we'd have a parallel universe.)


  • Here's my answer to Jim's question: "Would all of these 'complex attr values represented as IEntities' have identifiers?"
    • Not necessarily. At the F2F it was discussed that not all Entities have identifiers (EntityId Attributes). This is analogous to a "BlankNode" in RDF.
    • If you and your wife wish to share the same postal address, then the Entity representing you and the Entity representing her would each have a "homeAddress" attribute and both would have the same (shared) Entity as its value. In order to do this the shared postalAddress Entity would have to have an identifier so that you can refer to it in IdAS methods that set the value of attributes
    • My answer here is different from Drummond's answer because the HGG model is based very closely on RDF (with some syntactic differences + a couple of semantic generalizations) and in RDF you only have two options: the value is a literal or the value is another Resource (what we call an Entity). [One could always have a literal that was a URI that could refer to some other Resource, but this semantic is not supported by RDF.]
  • BTW, [off topic], one reason that I'm very excited to be removing metadata and replacing it with attributes on attributes is that by removing metadata we remove the last big difference from RDF (that is, after we make the change described on this page).
  • WRT Drummond's comment "Doesn't an Attribute whose value references another Entity become a Relation", my answer is "yes." One reason that I really think we should make the change proposed in this wiki page is that by doing so we can remove "Entity Relations" from the data model. In the past developers would specialize (technically "subproperty" in RDF) Entity Relation when they define their own kinds of relations, e.g. "reports to". But what I realized is that since a vanilla "Entity Relation" really just says "there is some unspecified relationship between these two Entities", it is (I now think) worthless. [A Entity Correlation OTOH is not worthless, it DOES have a defined meaning]. Now developers can define their own kinds of relations (e.g. reports to, knows, likes, etc.) as they please without specializing Entity Relation.

Drummond Replying to Paul

  • The only difference between the XDI model and your answer Paul is that the XDI model's third option is to be able address not just an Entity but a specific Attribute of that Entity. So my son's Entities could both reference that the value of their HairColor Attribute is the same as the value of my wife's Entity's HairColor Attribute (thank god they didn't get my hair ;-) But I don't think it's a problem if the HGG doesn't support than at first.
  • I agree that gaining complete alignment with RDF = a good thing. As you know, the XDI TC has already been through that same evolutionary path and arrived at the same conclusion.
  • Also agreed that Entity Relations are not needed if they are implied by any Attribute whose range is EntityId. One question: would there still be an easy way to query for such Attributes? In other words, could you ask an Entity to tell you all of its "relations" to other Entities (vs. its other Attributes that have literal values)?

See Also

Copyright © Eclipse Foundation, Inc. All Rights Reserved.