Re: LANG: pushing daml:collection was: Re: Is a non-RDF triples syntax out of charter?

My responses are mixed in below...

Jonathan Borden wrote:
> 
> Jeff Heflin wrote:
> > Jonathan Borden wrote:
> ...
> > >
> > > <Class rdf:ID="foo">
> > >         <oneOf>
> > >                 <Thing rdf:resource="#A"/>
> > >                 <Thing rdf:resource="#B"/>
> > >                 <Thing rdf:resource="#C"/>
> > >         </oneOf>
> > > </Class>
> > >
> > > This really isn't that bad XML.
> >
> > Your right, it isn't bad XML. In fact it is probably how I would suggest
> > such a thing be written in XML. Unfortunately, it's not RDF. ...
> > That is, you can't assume daml:collection,
> > it must be stated explicitly.
> 
> Sure. But that is proper use of an XML attribute, so:
> 
> <Class rdf:ID="foo">
>     <oneOf rdf:parseType="daml:collection">
>         <Thing rdf:resource="#A"/>
>         <Thing rdf:resource="#B"/>
>         <Thing rdf:resource="#C"/>
>     </oneOf>
> </Class>
> 
> is RDF, using an XML extension (parseType) extension. Asking RDFCore to
> enable something like "daml:collection" is something that we can do, and
> maintain our charter. That is to say, this is something that DAML+OIL has
> already done, parsers exist, software exists that understands this etc.

Yes, if RDFCore agrees to allow sucha parseType, then that will be
perfectly good RDF. However, my understanding that RDF core is reluctant
to do this, and frankly, I don't blame them. It doesn't seem like a very
natural extension to the language.

> > This is a syntactic wort. Common sense
> > tells you you shouldn't need it, but you can't write this in RDF without
> > it (and when you use it, you're not really writing RDF).
> 
> I would like to call it a syntactic compromise, and compromise is the name
> of the game.

However, too much of a compromise could result in a language that isn't
any good to anybody. We're not at that point yet, but I feel that this
particular compromise would significantly lessen both languages.

> [...]
> 
> >
> > Once again, this is fine XML, although maybe a little excessive (one
> > might argue whether you need the Class subelement of intersectionOf).
> > However, RDF won't allow this syntax. The problem is RDF syntax must be
> > striped (meaning you alternate Class/Property/Class/Property/etc.).
> > Assuming you follow RDF naming conventions of initial caps for classes
> > and initial lower case for properties, then you have a Restriction class
> > as the immediate child of the Class class. This is a no-no in RDF
> > because it violates the striping rule.
> 
> To be clear, RDF does not mandate that classes are capitalized and property
> names are lowercase. Well, the point is that whether this exact syntax is
> used, or modified just a bit to fit RDF, it remains close to what one might
> write in XML.
>
> >
> > > My questions are:
> > >
> > > What do I get by using another XML syntax? (what do I _actually get_)
> > > What does it cost me?
> > >
> > > I need concrete answers to these questions.
> >
> > By using another XML syntax you get:
> >
> > 1) more freedom in the design of your syntax. Thus you can make it more
> > intuitive and ease the learning barrier for users
> 
> I was not asking why another XML syntax _might_ be better, rather: show me
> an _actual_ alternative XML syntax so I can see _how much_ better it really
> is, given the cost of not being in RDF syntax.
> 
> >
> > 2) your syntax can more easily rule out things that shouln't be allowed.
> > For example, a daml:Restriction shouldn't mix "toClass" with "hasClass"
> > or "hasValue."
> 
> The abstract syntax for OWL could better prohibit illegal constructs. Indeed
> an OWL ontology for OWL should be a design goal (IMHO)-- rather than the
> current RDF Schema for DAML+OIL
> 
> >
> > 3) the semantics of the language is easier to specify, because it
> > doesn't have to represent all of the meta information included by the
> > triples.
> 
> Why not define semantics on the abstract OWL syntax (as proposed) and
> provide an RDF/XML representation?

Certainly you could do this. This was the "same syntax, diverging
semantics" option from the layering document. I'm not a particular fan
of it though.

> >
> > What does it cost?
> >
> > 1) existing RDFS agents will not be able to understand your WebOnt
> > ontologies (they can understand small portions of DAML+OIL ontologies.)
> >
> > 2) people may need to convert existing RDF Schemas in order to use
> > WebOnt
> >
> > Honestly, that's all I can think of. Maybe someone else can suggest
> > more?
> >
> 
> The actual cost is the creation of a rift in the semantic web community. I
> would like to see WebOnt language as "RDF Schema ++".
> 
> Other costs include need to develop parsers, and work through many of the
> nitty gritty details that RDFCore has dealt with -- this will be a cost in
> time and energy that looks like it will significantly delay the introduction
> of WebOnt. Think of it, it is already April, and still no sight of an
> alternative XML syntax. The only concrete syntax proposal is
> http://www.openhealth.org/WOWG/OWL.jj (JavaCC version of
> http://www.openhealth.org/WOWG/OWLnonXMLsyntax.txt ) -- I've yet to see much
> comment on this. We will need rounds and rounds of discussion about an
> alternate XML  syntax whenever it appears, development of parsers, debugging
> of issues, etc. etc. When will this happen?

I don't think the cost of developing parsers will be any less by
building directly on RDF Schema as opposed to using a straight XML
syntax. In the later case, we could reuse any number of the existing
validating XML parsers. We should also be able to specify some of the
syntactic constraints in the DTD or schema, which would have to be done
in additional code if we used a RDF Schema parser. In either case, the
code will still have to translate into some internal representation that
allows reasoning to occur (whether it be a common DL, a Prolog program,
specialized Java classes, etc.)

> >
> > > In the absense of an  actual concrete syntax I can't judge if the
> benefits
> > > would be worth the cost, regardless of what the charter allows.
> >
> > I agree that it hard to see these things without a concrete syntax. For
> > an example of concrete syntax that uses RDF-triples, see DAML+OIL[1].
> > That's about as good as it will get. Although I haven't suggested a
> > complete syntax for a non-RDF approach yet, I provide some examples of
> > what it could look like in my first message on this subject[2].
> 
> That is good, certainly we could rename "oneOf" to "or" and "intersectionOf"
> to "and" and maintain RDF compatibility. I am just not sure that removing
> the requirement for a few rdf:parseType="ont:collection" attributes will so
> greatly improve the readability of the syntax. On the other hand RDFCore is
> moving rapidly toward last-call WD, and if we don't make tangible and
> specific requests in the very near future, we are likely to miss the boat
> (in which case the RDF syntax i.e. writing everything out in full
> daml:List,first,rest glory will cause real pain - IMHO).
> 
> By pushing something very much like "daml:collection" we can have a big
> impact and make RDF syntax, warts and all, pretty reasonable.
> 
> Jonathan

Received on Monday, 1 April 2002 17:31:49 UTC