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

Context Data Model 1.1 Open Issues

Revision as of 16:00, 19 March 2008 by Paul.socialphysics.org (Talk | contribs) (Open Issues)

{{#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. This entire wiki page: HOWL is out of date with the rest of this wiki
  5. 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.)
  6. Worth noting somewhere: Node Relations are only an abstract super-types for real, useful relations like "memberOf", "reportsTo", "friend". Or "hasFavoriteBook", "hasCreditCard", etc.
  7. 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
  8. 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]
  9. 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?
  10. 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.

LDAP-specific Issues

See Also

Back to the top