Skip to main content
Jump to: navigation, search

Difference between revisions of "Context Data Model 1.1 Open Issues"

(Resolved Issues)
(Open Issues)
Line 8: Line 8:
 
# 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?)
# This entire wiki page: [[HOWL]] is out of date with the rest of this wiki
 
 
# Closed or open simple data types
 
# Closed or open simple data types
 
#* http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03821.html
 
#* http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03821.html

Revision as of 16:02, 19 March 2008

{{#eclipseproject:technology.higgins}}

Open Issues

  1. BlankNodes and Nodes.
    • The current HOWL and the current IdAS don't make a disctinction between a Node and a BlankNode. In the proposed HOWL update the BlankNode term is introduced. Currently both it and Node inherit separately from OWL:Thing.
    • Alternatives:
      • (a) Define Node to be a subclass of BlankNode: i.e. a Node is a BlankNode with a single literal NodeId attribute
      • (b) Don't introduce this distinction and call them both Nodes --most have a (single) literal NodeID attribute, some don't. --Paul.socialphysics.org 18:14, 4 March 2008 (EST)I'm leaning towards this one
  2. Can we represent closed (non-mixed) types in OWL so that the LDAP CP can represent its schema?
  3. 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?)
  4. 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.)
  5. Worth noting somewhere: Node Relations are only an abstract super-types for real, useful relations like "memberOf", "reportsTo", "friend". Or "hasFavoriteBook", "hasCreditCard", etc.
  6. 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
  7. 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]
  8. 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 Node (N1) that has two Node Relations emanating from it, e.g one pointing to N2 and another pointing to N3, then are you saying that we’re lacking a way to “tag” or otherwise distinguish between these two Node Relations?
  9. 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

  1. Mixed attribute value data types
    1. Daniel points out that it would still be good to pass type on each value add:
      1. http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03816.html
      2. http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03818.html (and follow-ups)
    2. Resolution: we can mix types.
  2. Can an attribute have mixed values consisting of both simple and complex?
    1. Resolution: Yes.
  3. Many same-types attributes
    1. http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03806.html
    2. Resolution: No. (We should document that this isn't allowed/possible)
  4. Allow zero-valued attributes
    1. http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03810.html
    2. 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.
  5. Replacement term for "Node".
    • Resolution: We had a vote and "Entity" won

LDAP-specific Issues

See Also

Back to the top