Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Dereferencing Complex Values Backlog"

(Paul)
(Paul)
Line 35: Line 35:
 
** 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.]  
 
** 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).
 
* 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 as they please (e.g. reports to) without specializing Entity Relation.
+
* 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.
  
 
== See Also ==
 
== See Also ==
 
* [[IdAS Backlog]]
 
* [[IdAS Backlog]]

Revision as of 23:43, 13 March 2008

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.addComplexValue(URI dataType)
 becomes:
   IEntity IAttribute.addComplexValue(IEntity)
 or maybe:
   IEntity IAttribute.addEntityValue(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.

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.

See Also

Back to the top