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 "Context Data Model 1.1 Open Issues"

m (Related to Higgins.owl's relationship to the IdAS API)
(Resolved Issues)
 
(70 intermediate revisions by 6 users not shown)
Line 1: Line 1:
==Related to Higgins.owl==
+
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
# Should we rename DatatypeAttribute to SimpleAttribute, and similarly, ObjectAttribute to ComplexAttribute? This would line up better with Jim's latest API
+
== Open Issues ==
# Higgins.owl: we need to add the full set of DatatypeAttribute subclasses that correspond to the XML Schema types. We currently have only StringDatatypeAttribute. We need to add Base64BinaryDatatypeAttribute, NormalizedStringDatatypeAttribute, ... and all the rest. (This is planned to be done prior to the next dev call on 9/28).
+
# Can we represent closed (non-mixed) types in OWL so that the LDAP CP can represent its schema?
# At present, other than having an Attribute subclass for each of the std OWL (XML Schema-based) literal datatypes, we have defined no ObjectAttribute subclasses. The question is should we go a bit further and define some very common complex types such as postalAddress? or even tricky singled-stringed values such as zipcode?
+
# 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?)
# We need to develop an example of an ontology that is based on higgins.owl but that emphasises how to model relationships between [[Digital Subject]]s
+
# 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.)
 +
# 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: [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]
 +
# 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]
 +
# Need to close on [[EntityId]] requirements and design decisions as documented on [[EntityId Requirements]].
  
==Related to higgins.owl's relationship to the IdAS API==
+
==Additions Needed==
# API currently assumes that the 'type' of the value of an Attribute can be determined a priori by an examination of the 'type' (see getType() on IProperty) of the IAttribute (IProperty). At best only a the supertype can be a priori determined, and in some cases multiple supertypes are allowed. (Details in Paul's email to Jim and the higgin-dev list of Fri 9/22)
+
# New Classes and Attributes to support Access Control (e.g. PolicySet, Policy, higgins:audience (permission to whom), higgins:operation (what operation is permitted) higgins:resource (thing being protected)
 +
# I-Card Class and associated Attributes: standard way to represent ISIP M- and P-Cards. Also an R-Card Class (subclass of I-Card)
 +
 
 +
== Resolved Issues ==
 +
# BlankEntities
 +
#* 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 Entities
 +
#* See [[HOWL Update 1.1.103]] for proposed resolution to this issue (based on (b) above)
 +
# Mixed attribute value data types
 +
## Daniel points out that it would still be good to pass type on each value add:
 +
### http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03816.html
 +
### http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03818.html (and follow-ups)
 +
## 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.
 +
# Replacement for Node (by vote, winner was Entity)
 +
 
 +
== LDAP-specific Issues ==
 +
* [[LDAP Issues and To-Dos]] --open issues specifically related to LDAP schema

Latest revision as of 20:09, 13 April 2009

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Open Issues

  1. Can we represent closed (non-mixed) types in OWL so that the LDAP CP can represent its schema?
  2. 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?)
  3. 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.)
  4. 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
  5. 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]
  6. 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?
  7. 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]
  8. Need to close on EntityId requirements and design decisions as documented on EntityId Requirements.

Additions Needed

  1. New Classes and Attributes to support Access Control (e.g. PolicySet, Policy, higgins:audience (permission to whom), higgins:operation (what operation is permitted) higgins:resource (thing being protected)
  2. I-Card Class and associated Attributes: standard way to represent ISIP M- and P-Cards. Also an R-Card Class (subclass of I-Card)

Resolved Issues

  1. BlankEntities
    • 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 Entities
    • See HOWL Update 1.1.103 for proposed resolution to this issue (based on (b) above)
  2. 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.
  3. Can an attribute have mixed values consisting of both simple and complex?
    1. Resolution: Yes.
  4. 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)
  5. 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.
  6. Replacement for Node (by vote, winner was Entity)

LDAP-specific Issues

Back to the top