Joint Committee Minutes 23 January 2001

Participants

• Tim Berners-Lee (joined late)
• Mike Dean
• Stefan Decker
• Jeff Heflin
• Jim Hendler
• Ian Horrocks
• Deb McGuinness (joined late)
• Peter Patel-Schneider
• Lynn Andrea Stein

Announcements

www.daml.org will down on on Thursday, January 25, from 5-6pm EST to move to a new server and IP address.

Last Week's Minutes

Concrete Types

Santa and his associatedData in the revised example shows the use of an "any" or "top" type whose actual type (any concrete type) is declared when the value is instantiated. This is useful, but it's not clear that XML Schema has a corresponding mechanism. Also, the example shows the property as untyped -- perhaps we should have an explcit type indicator such as "top".

Jeff questioned the need to use different parallel properties (e.g. hasDataType/hasClass) for restrictions on concrete and abstract classes, increasing the size of the DAML namespace. Peter indicated that reusing the same properties probably wouldn't complicate the semantics, but they have different ranges.

Tim expressed a desire for properties that could take on either concrete or abstract values, e.g. a title that could be a string or an object containing multiple translations of that title into different languages. This conflicts with the disjoint-ness of concrete and abstract types in the current proposal. Mike suggested adding a higher level "top" that could allow either concrete or abstract types. ACTION (Tim): Provide examples motivating the ability to mix concrete and abstract types.

There was some discussion of including a set of boxed classes (analogous to java.lang.Integer) as part of a "standard library" accompanying the DAML language. Each would contain a value of the corresponding concrete type.

As part of a group effort to achieve closure on concrete types, Deb made a motion that we accept the current concrete types proposal at next week's meeting. ACTION (everyone): review the current proposal, post any counter-proposals to [email protected], and be prepared for final discussion and a vote. Counter-proposals may include specific changes to DAML+OIL(+CONCRETE) and/or specific mechanisms or documentation to allow for future language extensions.

Language Change Impacts on Tool Developers

Qualified Restrictions

If we want to say that a Person can have at most 10 children, we could write

<daml:Restriction>
  <daml:onProperty rdf:resource="#hasChild"/>
  <daml:hasClass rdf:resource="#Person"/>
  <daml:maxCardinality>10</daml:maxCardinality>
</daml:Restriction>

<daml:Restriction>
  <daml:onProperty rdf:resource="#hasChild"/>
  <daml:hasClassQ rdf:resource="#Doctor"/>
  <daml:maxCardinalityQ>3</daml:maxCardinality>
</daml:Restriction>

If there were no distinction between hasClass and hasClassQ, this would *also* say that there are at most 3 doctors overall, which is not what is intended.

It would be desirable to put an example like this in the walkthrough.

RuleML Interaction

Next Week

• Final (hopefully) discussion on concrete types.
• Discussion on DAML PI meeting: Language breakout session (as at the DAML kickoff meeting), less formal Birds-of-a-Feather sessions (DAML-Rules?, Ontology Translation?, ...).

Links