RE: Review of the Syntax document (action 312)

Hello,

[snip]

> >>
> >> if I am right, I would propose to drop the 'Declaration(' part. It does
> >> means some more editorial work in the syntax and the mapping document,
> >> but it does not seem to be a huge one. Actually, it would also make it a
> >> little bit closer to the RDF way of declaration, which is a plus.
> >>
> >> (I realise this change request comes a bit late in the game, so I will
> >> not stick to it if the overall feeling is that it is not worth the trouble)
> >>
> >>
> >
> > This change could be made -- that is, the syntax would work. I agree that
> the
> > syntax would become much nicer.
> >
> > The only downside I can see is that the FSS would depart slightly from the
> > structural specification: in the SS, we have the Declaration class, which
> > currently nicely corresponds with the 'Declaration' terminal. (A similar
> > situation exists in the XML Syntax and is necessary there.) I think I could
> live
> > with this: it is just us recognizing that UML is different from a linear
> syntax.
> >
> > I don't think, however, that I can just change this, so I suggest to discuss
> > this at the next teleconf.
> 
> Actually... I saw Bijan's argument that this is the only way we can
> consistently use annotation constructs, which is quite convincing. That
> and the fact that we should not reopen closed issues if we can avoid it
> makes me revoke this comment and proposal. So let us consider that it as
> moot.
> 

Actually, there is no problem at all, as we could use the following syntax:

Declaration := ClassDeclaration | ObjectPropertyDeclaration | ...
ClassDeclaration := 'Class' '(' axiomAnnotations Class ')'
ObjectPropertyDeclaration := 'ObjectProperty' '(' axiomAnnotations
ObjectProperty ')'
...

Thus, instead of putting the annotations inside the 'Declaration' terminal, you
just put them into the 'Class' terminal.

I guess the biggest question here is whether we care about the fact that FSS
would seem to slightly diverge from the SS: currently FSS uses the 'Declaration'
terminal that seems to match with the Declaration UML class in the SS.

[snip]

> >
> > You must have been reading the document while I've been implementing the
> CURIE
> > change. This part of the document has changed now considerably, so please
> let me
> > know should you have any comments about the new version.
> >
> >
> 
> Section 2.4, 4th paragraph:
> 
> "Certain concrete syntaxes, such as the RDF Syntax [OWL 2 RDF Mapping],
> allow IRIs to be abbreviated in relation to the IRI of the document they
> are contained in."
> 
> There is no such thing as a (generic) 'RDF Syntax'. I guess you refer to
> the RDF/XML syntax (and then the reference should also be changed).
> 

You're right: the IRI abbreviation mechanism I'm referring to here is
independent from whether you are encoding OWL ontologies in RDF or not. I've
changed the sentence like this:

Concrete syntaxes such as the RDF/XML Syntax
[<cite>[[#ref-rdf-xml|RDF/XML]]</cite>] allow IRIs to be abbreviated in relation
to the IRI of the document they are contained in.

> 
> [skip]
> 
> >> ------
> >> 3.6. Canonical parsing
> >>
> >> The typesetting used for the items is such that 'CP-3.2' has a line
> >> break after '-' and '3.2'. This is at least the way it looks in my
> >> browser (Chrome) but also on Safari. I find it a bit difficult to read,
> >> shouldn't that be in one line?
> >>
> >
> > I've changed '-' to &ndash; so it should not break any more. Please let me
> know
> > if the problems persist.
> 
> It does:-(
> 

I've changed now &ndash; to &nbsp;. The latter is called a *nonbreaking* space,
so it should work; if it doesn't, then I'm out of my depth. Welcome to the
wonders of HTML typesetting!

> [skip]
> 
> 
> >
> > You are right -- this is a bit messed up. There are several problems here.
> >
> > - I deliberately didn't want to talk in this document about the syntactic
> things
> > (i.e., individuals and literals) independently from their semantic meaning
> > (i.e., domain objects and data values). Hence, I glossed over the
> distinction
> > between literals and the data values that the literals stand for. I'm not
> really
> > sure whether going there is worth it: it would just make the formulations
> > tricky.
> >
> > -  I agree, however, that the formulation was broken here. I've changed it
> to
> > talk about tuples of literals.
> >
> > - I (silently) consider a tuple of one literal to be the same as the actual
> > literal. This is why, for DataOneOf, I don't talk about tuples any more but
> of
> > simply literals. Let me know whether you consider this worth an explicit
> > discussion.
> >
> 
> We may want to add a remark in the introduction of Data Ranges that a
> singleton tuple is considered identical to the tuple element itself,
> although that is one of the syntactic 'abuses' that is often done
> elsewhere, too.
> 
> Otherwise this (plus the other changes you did on datatypes) look o.k.
> to me!
> 

I've changed the first sentence like this:

Datatypes, such as strings or integers, can be used to express data ranges
&mdash; sets of tuples of literals, where tuples consisting of only one literal
are identified with the literal itself.

[snip]


Thanks again for your comments!

Regards,

	Boris

Received on Monday, 30 March 2009 09:59:20 UTC