Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Context Data Model 1.1 Open Issues"
m (Global Graph Open Issues moved to Context Data Model Open Issues) |
|||
Line 1: | Line 1: | ||
{{#eclipseproject:technology.higgins}} | {{#eclipseproject:technology.higgins}} | ||
== Open Issues == | == Open Issues == | ||
− | # | + | # BlankEntities and Entities. |
− | #* The current HOWL and the current IdAS don't make a | + | #* The current HOWL and the current IdAS don't make a distinction between an Entity and a BlankEntity. In the proposed HOWL update the BlankEntity term is introduced. Currently both it and Entity inherit separately from OWL:Thing. |
#* Alternatives: | #* Alternatives: | ||
− | #** (a) Define | + | #** (a) Define Entity to be a subclass of BlankEntity: i.e. an Entity is a BlankEntity with a single literal EntityId attribute |
− | #** (b) Don't introduce this distinction and call them both | + | #** (b) Don't introduce this distinction and call them both Entiteis--most have a (single) literal EntityID attribute, some don't. --[[User:Paul.socialphysics.org|Paul.socialphysics.org]] 18:14, 4 March 2008 (EST)I'm leaning towards this one |
# Can we represent closed (non-mixed) types in OWL so that the LDAP CP can represent its schema? | # Can we represent closed (non-mixed) types in OWL so that the LDAP CP can represent its schema? | ||
# Ability to declare user-defined Classes to be 'closed', that is instances of them should follow the class definition, but not include any other "extra" properties. (same as previous?) | # Ability to declare user-defined Classes to be 'closed', that is instances of them should follow the class definition, but not include any other "extra" properties. (same as previous?) | ||
Line 12: | Line 12: | ||
#* Paul asserts that we have the ability already to specify a format constraint along with a data type. For example, one could say the data type of an attribute is normalizedString, but constrained to a pattern that looks like a telephone number | #* Paul asserts that we have the ability already to specify a format constraint along with a data type. For example, one could say the data type of an attribute is normalizedString, but constrained to a pattern that looks like a telephone number | ||
#* We can do this by creating a [[Data Range]]. A [[Data Range]] has a base XML Schema type (e.g. string) as well as all of the XML Schema facets (e.g. pattern, etc.) | #* We can do this by creating a [[Data Range]]. A [[Data Range]] has a base XML Schema type (e.g. string) as well as all of the XML Schema facets (e.g. pattern, etc.) | ||
− | # Worth noting somewhere: | + | # Worth noting somewhere: Entity Relations are only an abstract super-types for real, useful relations like "memberOf", "reportsTo", "friend". Or "hasFavoriteBook", "hasCreditCard", etc. |
# Tony: We don't have a simplified description of the data model | # Tony: We don't have a simplified description of the data model | ||
#* Need a simple-to-follow set of pictures that explain the data model | #* Need a simple-to-follow set of pictures that explain the data model | ||
#* This PPT was updated to the latest concepts terms and improved a bit based on feedback from the Jan/Provo F2F: [http://dev.eclipse.org/viewsvn/index.cgi/org.eclipse.higgins/trunk/doc/org.eclipse.higgins.doc/Higgins-Data-Model-Intro.ppt?root=Technology_SVN&view=co Higgins Data Model Intro.PPT] | #* This PPT was updated to the latest concepts terms and improved a bit based on feedback from the Jan/Provo F2F: [http://dev.eclipse.org/viewsvn/index.cgi/org.eclipse.higgins/trunk/doc/org.eclipse.higgins.doc/Higgins-Data-Model-Intro.ppt?root=Technology_SVN&view=co Higgins Data Model Intro.PPT] | ||
# This is a runtime data model, there are not yet any tools that can create the graphs that I think folks might need. Restating: The data mode is an un-typed mode, (no sub-classes) makes you look at each instance to determine its type, this is not suitable for data mining and creating graphs of the data characteristic. [from Tony 2/21 higgins-dev email] | # This is a runtime data model, there are not yet any tools that can create the graphs that I think folks might need. Restating: The data mode is an un-typed mode, (no sub-classes) makes you look at each instance to determine its type, this is not suitable for data mining and creating graphs of the data characteristic. [from Tony 2/21 higgins-dev email] | ||
− | # When using relations there is now way to tell what relation we are really talking about. [from Tony 2/21/08 higgins-dev email]. Restated by Paul in 2/21/08 email: Given | + | # When using relations there is now way to tell what relation we are really talking about. [from Tony 2/21/08 higgins-dev email]. Restated by Paul in 2/21/08 email: Given Entity (E1) that has two Entity Relations emanating from it, e.g one pointing to E2 and another pointing to E3, then are you saying that we’re lacking a way to “tag” or otherwise distinguish between these two Entity Relations? |
# Another "core" subclass to consider is Account (or something that represents the attributes needed to authenticate to a system). It is important to figure this out early in the subclassing, because many repositories represent accounts as additional attributes of a Person and other repositories represent the account as separate from the Person. In addition not all accounts are Persons, the account could represent a device, application, or a group. [David K-M email of 2/22/08 on higgins-dev] | # Another "core" subclass to consider is Account (or something that represents the attributes needed to authenticate to a system). It is important to figure this out early in the subclassing, because many repositories represent accounts as additional attributes of a Person and other repositories represent the account as separate from the Person. In addition not all accounts are Persons, the account could represent a device, application, or a group. [David K-M email of 2/22/08 on higgins-dev] | ||
Line 35: | Line 35: | ||
## http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03810.html | ## http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03810.html | ||
## Resolution: we should not allow zero-valued attributes in the model per se. It is true that for access control reasons, no value will be returned in some cases. | ## Resolution: we should not allow zero-valued attributes in the model per se. It is true that for access control reasons, no value will be returned in some cases. | ||
− | + | ||
− | + | ||
== LDAP-specific Issues == | == LDAP-specific Issues == |
Revision as of 21:15, 27 April 2008
{{#eclipseproject:technology.higgins}}
Open Issues
- BlankEntities and Entities.
- The current HOWL and the current IdAS don't make a distinction between an Entity and a BlankEntity. In the proposed HOWL update the BlankEntity term is introduced. Currently both it and Entity inherit separately from OWL:Thing.
- Alternatives:
- (a) Define Entity to be a subclass of BlankEntity: i.e. an Entity is a BlankEntity with a single literal EntityId attribute
- (b) Don't introduce this distinction and call them both Entiteis--most have a (single) literal EntityID attribute, some don't. --Paul.socialphysics.org 18:14, 4 March 2008 (EST)I'm leaning towards this one
- Can we represent closed (non-mixed) types in OWL so that the LDAP CP can represent its schema?
- Ability to declare user-defined Classes to be 'closed', that is instances of them should follow the class definition, but not include any other "extra" properties. (same as previous?)
- Closed or open simple data types
- http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03821.html
- Paul asserts that we have the ability already to specify a format constraint along with a data type. For example, one could say the data type of an attribute is normalizedString, but constrained to a pattern that looks like a telephone number
- We can do this by creating a Data Range. A Data Range has a base XML Schema type (e.g. string) as well as all of the XML Schema facets (e.g. pattern, etc.)
- Worth noting somewhere: Entity Relations are only an abstract super-types for real, useful relations like "memberOf", "reportsTo", "friend". Or "hasFavoriteBook", "hasCreditCard", etc.
- Tony: We don't have a simplified description of the data model
- Need a simple-to-follow set of pictures that explain the data model
- This PPT was updated to the latest concepts terms and improved a bit based on feedback from the Jan/Provo F2F: Higgins Data Model Intro.PPT
- This is a runtime data model, there are not yet any tools that can create the graphs that I think folks might need. Restating: The data mode is an un-typed mode, (no sub-classes) makes you look at each instance to determine its type, this is not suitable for data mining and creating graphs of the data characteristic. [from Tony 2/21 higgins-dev email]
- When using relations there is now way to tell what relation we are really talking about. [from Tony 2/21/08 higgins-dev email]. Restated by Paul in 2/21/08 email: Given Entity (E1) that has two Entity Relations emanating from it, e.g one pointing to E2 and another pointing to E3, then are you saying that we’re lacking a way to “tag” or otherwise distinguish between these two Entity Relations?
- Another "core" subclass to consider is Account (or something that represents the attributes needed to authenticate to a system). It is important to figure this out early in the subclassing, because many repositories represent accounts as additional attributes of a Person and other repositories represent the account as separate from the Person. In addition not all accounts are Persons, the account could represent a device, application, or a group. [David K-M email of 2/22/08 on higgins-dev]
Resolved Issues
- Mixed attribute value data types
- Daniel points out that it would still be good to pass type on each value add:
- Resolution: we can mix types.
- Can an attribute have mixed values consisting of both simple and complex?
- Resolution: Yes.
- Many same-types attributes
- http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03806.html
- Resolution: No. (We should document that this isn't allowed/possible)
- Allow zero-valued attributes
- http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03810.html
- Resolution: we should not allow zero-valued attributes in the model per se. It is true that for access control reasons, no value will be returned in some cases.
LDAP-specific Issues
- LDAP Issues and To-Dos --open issues specifically related to LDAP schema