Skip to main content
Jump to: navigation, search

Difference between revisions of "Dereferencing Complex Values Backlog"

(Notes from 20080420 Higgins F2F)
Line 67: Line 67:
 
** Proposal:  Don't treat referenced to other entities as complex values
 
** Proposal:  Don't treat referenced to other entities as complex values
 
*** A new kind of attribute value will be created which will be of type "reference"
 
*** A new kind of attribute value will be created which will be of type "reference"
 +
**** [https://bugs.eclipse.org/bugs/show_bug.cgi?id=235699 bug 235699]
 
*** Non-shared complex attributes can still be a blank entity.
 
*** Non-shared complex attributes can still be a blank entity.
 +
**** [https://bugs.eclipse.org/bugs/show_bug.cgi?id=228076 bug 228076]
 
*** With this proposal, we no longer fake named nodes as if they were unnamed nodes.
 
*** With this proposal, we no longer fake named nodes as if they were unnamed nodes.
 
*** This proposal also solves most of the other problems presented (Access Control, Updates, Loop Detection)
 
*** This proposal also solves most of the other problems presented (Access Control, Updates, Loop Detection)
 
*** We should consider some way in which a caller can ask: "get me this attribute value, and if it's a reference type, then dereference it and return me what the reference pointed at.
 
*** We should consider some way in which a caller can ask: "get me this attribute value, and if it's a reference type, then dereference it and return me what the reference pointed at.
 
**** If we do this, will we also need matching rules that are capable of this kind of dereferencing?
 
**** If we do this, will we also need matching rules that are capable of this kind of dereferencing?
 +
**** [https://bugs.eclipse.org/bugs/show_bug.cgi?id=235705 bug 235705]
  
 
== See Also ==
 
== See Also ==

Revision as of 16:26, 4 June 2008

{{#eclipseproject:technology.higgins}}

Higgins logo 76Wx100H.jpg

About

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

Proposal

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

Examples...

 this:
   IComplexAttrValue IAttribute.getComplexValue(URI dataType)
 becomes:
   IEntity IAttribute.getComplexValue(IEntity)
 or maybe:
   IEntity IAttribute.getEntityValue(IEntity)
 IComplexAttrValue <-- goes away

Questions/Observations

Jim

  • 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.

Jim again (20080325)

  • Using IdAS, how would we add a complex value?
    • We could add a method like IEntity IEntity.addComplexValue(URI type, URI name);
      • where name is optional and will create an unnamed entity if null
  • How do we show non-support for values which are named entities?
    • The LDAP provider can't support values that are named entities.
  • We will have to do a refactor of search filters for this.
  • Given a named IEntity, do we want/need to know what uses it as a value?
  • If a referenced IEntity is modified, does it change all values that refer to it, or is an unnamed copy made?
    • Is the behavior above the same whether the IEntity is updated via a referencing IEntity versus getting it from IContext?
  • How does access control work when you can edit your own home address but no one else's, and it turns out that you share the home address attr?
    • Could have policy that performs a “copy to unnamed entity on update”
      • Seems like this action would need to be made known to the consuming application. Also seems like a good idea to allow the consuming application to specify whether or not “copy to unnamed entity on update” is allowed.
  • Similar access control questions for read.

Another consideration mentioned on the Mar 27th call:

  • When you do a query that returns an IEntity that is in turn has IEnitity-valued attributes, etc. the client needs to be able to control as part of the query just how many cascading levels of IEntity are desired.
  • Does IdAS use the design pattern where it returns lightweight stub "IEntity" proxy objects that shadow real IEntity objects that are lazily returned

Drummond

  • 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.)

Paul

  • 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)? --Paul.socialphysics.org 06:59, 14 March 2008 (EDT) Great question. But now it is an IdAS API design question as opposed to a data model question. The data model can distinguish between literal-valued and Entity-valued values. The question is whether or not we want to add IAttribute.getSimpleValues() and IAttribute.getComplexValues() methods to the API. Or whether the existing API calls are good enough, etc. Jim?

Notes from 20080420 Higgins F2F

  • Maybe simple attributes should not be shared. Or at least we should remove that requirement from this discussion
  • Management of references
    • Most of the proposals so far would have us supporting references to other first-class entities as if they were simply attribute values. This becomes a problem when one wants to manage the reference. If one always gets back an IEntity, there's no way to change the reference to another IEntity.
    • Proposal: Don't treat referenced to other entities as complex values
      • A new kind of attribute value will be created which will be of type "reference"
      • Non-shared complex attributes can still be a blank entity.
      • With this proposal, we no longer fake named nodes as if they were unnamed nodes.
      • This proposal also solves most of the other problems presented (Access Control, Updates, Loop Detection)
      • We should consider some way in which a caller can ask: "get me this attribute value, and if it's a reference type, then dereference it and return me what the reference pointed at.
        • If we do this, will we also need matching rules that are capable of this kind of dereferencing?
        • bug 235705

See Also

Back to the top