From: Jeff Heflin (heflin@cs.umd.edu)
Date: 01/30/01
Ian Horrocks wrote: > > While I have some sympathy with Jeff's wish to simplify the syntax, I > think there are some serious problems with his proposal (Peter has > already pointed out some). Moreover, the simplification idea seems to > be predicated on the assumption that people will be generating > daml+oil using a text editor. I believe that, on the contrary, we > should assume that only experts/masochists will work this way, and > that everyone else will use more sophisticated tools. For such tools, > the more complex syntax wont be a problem and may even be beneficial > as it is more precise and easier to parse. While I agree that tools might eventually hide syntax from ordinary users, I don't think the Web community will get behind a language and develop the tools for it if they find the language awkward and cumbersome. > As far as tools are concerned, you are no doubt sick of hearing me > tell you about OilEd, and I believe that both Protege and OntoEdit > will/do support daml+oil. Any sane person should use such tools and > let them worry about the syntax. If an expert wants to write daml+oil > directly, they can do it, but we should assume that they are able to > look after themselves. Experts may even want to write something like: > > <daml:Restriction> > <daml:onProperty rdf:resource="#hasChild" /> > <daml:hasClass rdf:resource="#tall"> > <daml:onProperty rdf:resource="#hasParent" /> > <daml:hasClass rdf:resource="#short"> > </daml:Restriction> > > as it is much more compact than the expanded intersection of > restrictions (experts are like that). I'm afraid I don't quite get this example. Didn't we determine that the semantics would say that this restriction is something that "has a child who is tall and short and a parent that is is tall and short," which assuming tall and short have their traditional definitions is the empty set? If we are to interpret this as "has a tall child and a short parent", then we need to be able to preserve the ordering of the properties on the Restriction, which the RDF graph model doesn't do. > The proposal also breaks the separation between concrete and abstract > domains because we can have things like: > > <daml:complementOf> > <daml:Restriction> > <daml:onProperty rdf:resource="#hasHeight" /> > <daml:toType rdf:resource="#tall"> > </daml:Restriction> > </daml:complementOf> > > which states describes the class of objects that have a height that is > either an instance of the abstract class "tall" or a concrete data > value. It was to avoid this problem that the separation of concrete > and abstract properties was introduced. If hasHeight had a range defined, then this problem would be avoided. If not, then you are correct. However, I think if we specified that certain troublesome constructs like this were undefined, then DL systems could simply ignore things that would give them trouble. > I have also added a few comments below. I have also replied to a few comments below. > Regards, Ian > > On January 29, Jeff Heflin writes: > > Ian and Peter's concrete datatypes proposal [1] prompted a great deal of > > discussion on RDF Logic and last week's telecon. Although I think that > > in general the proposal is very good, I have expressed a feeling that > > some of the additional syntax was unnecessary (see RDF logic for > > background of the discussion). Here, I move that Ian and Peter's > > proposal for concrete datatypes be accepted, but with with the following > > changes to simplify syntax: > > > > 1) add a class called daml:Type > > > > 2) both rdfs:Class and daml:DataType are subClassOf daml:Type > > There could be instances of daml:Type that are neither rdfs:Classes > nor daml:DataTypes. This is a problem when using daml:Type as a range > restriction. I mention this in my paragraph about disadvantages, where I suggest that we could specify that such situations default to being in the abstract domain or are undefined (our choice). > > 3) remove daml:onConcreteProperty and change the range of > > daml:onProperty to rdfs:Property > > > > 4) replace daml:toClass and daml:toDataType with daml:toType, which has > > domain daml:Restriction and range daml:Type > > > > 5) remove daml:hasDataValue (use daml:hasValue for both class and > > datatype values) > > > > 6) replace daml:hasClass and daml:hasDataType with daml:hasType, which > > has domain daml:Restriction and range daml:Type > > > > 7) replace daml:hasClassQ and daml:hasDataTypeQ with daml:hasTypeQ, > > which has domain daml:Restriction and range daml:Type > > > > 8) for DAML purposes, rdfs:range will have range daml:Type (so we can > > express ranges using data types) > > In other words, you need to break/change RDFS for this to work. In your original concrete datatype proposal, data types can't be used as ranges; in order to do so would require the same change. I was just trying to fix what I saw as an ommission. Beside, breaking/changing RDF hasn't stopped us before ;-) > > 9) change the type of daml:onProperty to daml:UniqueProperty (so that a > > daml:Restriction can have at most one daml:onProperty, disallowing the > > odd semantics that occur when someone tries to define multiple > > restrictions within a single <Restriction> element). > > I am very much opposed to using daml+oil constructs to apparently > specify/constrain the language itself as daml+oil does not in general > confer any semantics on such usages. I don't quite understand your aprehension here. If I had used daml:cardinality=1 (which requires a daml:Restriction and daml:onProperty to be specified) then I could see problems with the circularity of the definition. That's why I chose to make it a daml:UniqueProperty, which is really just a form of bootstrapping the language. > > As I see it, the advantages of this proposal are: > > > > 1) users don't need to learn separate syntaxes to express restrictions > > for concrete properties vs. abstract properties > > See my opening remarks - users don't need to learn any syntax, they > just need to use a suitable tool. > > > 2) when we extend the language with other semantic primitives, we don't > > need to create distinct concrete domain primitives that correspond to > > each abstract domain primitive > > This is a hassle for us, but shouldn't worry users of suitable tools. > > > 3) we still restrict what can be said about the concrete domain. For > > example, you can't have a DataType as range of rdf:type (so users can't > > specify new instances of a data type), as range of rdfs:domain (so no > > property can have a data type as its domain), or as the domain and range > > of rdfs:subClassOf (so no hierarchical relationships can be specified). > > > > A possible disadvantage is that there may be properties for which it is > > unknown whether they belong to the concrete or abstract domains (i.e., > > if the property is of type rdfs:Property (as opposed to AbstractProperty > > or ConcreteProperty) and has no range or range that is daml:Type. It is > > also possible that a property may specify ranges from both the abstract > > and concrete domains. However, we could probably suggest reasonable > > behaviours for each of the situations (e.g., a property is assumed to be > > abstract unless otherwise specified, a property with ranges from both > > domains is invalid). > > > > Jeff > > > > [1] http://www.cs.man.ac.uk/~horrocks/daml+oil/Datatypes/
This archive was generated by hypermail 2.1.4 : 04/02/02 EST