Re: Action 299 - removing sorts

> Hi Michael,
> 
> > OK, Dave, I think I took care of your comments, so please take a look.
> > Hopefully you find this version much better.
> 
> Yes, thank you.
> 
> I'm not sure about the introduction of the two subclasses of PRIMTYPE in 
> the abstract syntax and they are not described anywhere yet (unless I 
> missed it). I assume RIFTYPE is supposed to include rif:local and 
> rif:iri and XMLTYPE is supposed to include xsd:* plus rdf:XMLLiteral.
> I don't object, I just don't yet understand the value of such a subdivision.

I am not sure either. We are going from ebnf to asn, and due to our
imperfect understanding of asn the latter sometimes looks confusing.


> When we do a pass at the human readable syntax then the EBNF will need 
> updating. Const would presumably now be:
>     Const ::= ''' CONSTNAME ''' | '"' CONSTNAME '"' '^^' TYPENAME

I am not sure this is correct.
CONSTNAME without the ^^ is used for shorthands. This includes decimals,
which are written as 1.23 and local constants, which look like 'a bc'.

So, some do not have the quotes. The current doc says: "The first form is
used as a shorthand for some data types, like long integers, decimals,
local RIF constants, etc. The precise syntax for RIF constants is given in
Section Primitive Data Types."

I think it is better to leave CONSTNAME undefined here and to explain the
syntax in that section on Primitive Data Types.

> However, as I said before I'd rather we took a separate pass at the EBNF 
> concrete syntax, which is currently underspecified. If we do decide that 
> it is worth having a fully specified EBNF notation then we should 
> consider including some syntactic machinery to enable prefix declaration 
> and optional curie format for iris.

ok 


	--michael  


> Dave
> -- 
> Hewlett-Packard Limited
> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
> 
> 
> > 
> > 
> > 	thanks
> > 	  --michael  
> > 
> > 
> >> Michael Kifer wrote:
> >>>> Unless I'm missing something there is nothing in that section concerning 
> >>>> typed literal data values. There seems to be no mention of them in 
> >>>> either the abstract syntax or the semantics, just a list of xsd types at 
> >>>> the front.  Is that material now somewhere else or is it work in 
> >>>> progress or am I just blind? [*]
> >>>>
> >>>> Similarly whilst the introduction says that IRIs are used to refer to 
> >>>> individuals, predicates and functions the abstract syntax doesn't yet
> >>>> support that.  [Reasonable at this stage, I'm just noting it so we don't 
> >>>> forget it.]
> >>>
> >>> Dave,
> >>> I have now updated the document to include the discussion of the abstract data
> >>> type in the formal/concrete syntax and semantics. Will appreciate feedback.
> >> Thanks.
> >>
> >> I'm not completely happy with those sections yet. I'll outline my 
> >> comments below but if you'd rather I generated some alternative draft 
> >> text sections, to be critiqued in return, then I could do so. It just 
> >> seemed preferable to agree the principles before getting too much into 
> >> word-smithing.
> >>
> >> ** Summary
> >>
> >> My reservations are:
> >>    - treatment of rif:iri (surprise :-) )
> >>    - request for abstract syntax modifications (relates to above)
> >>    - need for XMLLiteral
> >> and at a minor presentational level:
> >>    - separation of abstract, human-readable and XML syntax discussion?
> >>    - degree of tie in to XML Schema datatypes
> >>    - trivial terminology quibble
> >>
> >> ** Treatment of rif:iri
> >>
> >> I'm not convinced we should be treating rif:iri as a datatype.
> >>
> >> Setting aside rif:iri for a moment, then the set Const has subsets 
> >> Const\sub{xsd:string} etc and elements which are members of none of 
> >> those subsets. In the example:
> >>
> >>     purchase(?Buyer ?Seller book(?Author "LeRif"^^xsd:string)
> >>                      USD("49"^^xsd:long))
> >>
> >> then the Consts identified by 'purchase', 'book' and 'USD' are all of 
> >> latter category. These are simply Consts (with associated signatures 
> >> induced by context, e.g. Const(purchase) has signature p4{} as well as i{}).
> >>
> >> As we know from previous discussions, I would like to use IRIs as the 
> >> lexical label for all of those Consts, you would like to permit both 
> >> simple strings and IRIs.
> >>
> >> My preferred solution to this is to divide Const into three subsets:
> >>
> >> ConstL  - semantically unconstrained, labelled by simple strings
> >>
> >> ConstW  - semantically unconstrained, labelled by IRIs (w for "web")
> >>
> >> ConstD  - typed constants comprising subsets Const\sub{xsd:string} etc, 
> >> each subset constrains I\sub{C} according to the lexical-to-value 
> >> mapping of the associated datatype so that each instance denotes a fixed 
> >> semantic object.
> >>
> >> In the abstract syntax (and thus the human and XML concrete syntaxes) 
> >> these would be distinguished.
> >>
> >> In terms of the semantics, ConstL and ConstW place no constraints on 
> >> I\sub{C} just as for non-typed Consts at the moment.
> >>
> >> The advantages of this are (a) it makes clear that IRIs are here just 
> >> used as identifiers, (b) it makes the treatment of constants labelled by 
> >> local-strings and those labelled by IRIs symmetric, (c) it makes it 
> >> easier for dialects to restrict the syntax to require all Consts to be 
> >> denoted by IRIs as might be desired in a dialect to support exchange of 
> >> RDF rules.
> >>
> >> ** Abstract syntax modifications
> >>
> >> Currently the abstract syntax does not provide for datatype labelling. 
> >> The section "Syntax for Primitive Types" demonstrates a human and XML 
> >> concrete syntax for this but given the WG's decision to maintain the 
> >> asn06 abstract syntax as primary then that needs updating as well.
> >>
> >> Given my above suggestion for treatment of IRIs then I would suggest 
> >> replacing:
> >>
> >> [[[
> >> class TERM
> >>
> >>      subclass Const
> >>          property name: xsd:string
> >> ]]]
> >>
> >> by something like:
> >>
> >> [[[
> >> class TERM
> >>      subclass CONST
> >>          subclass ConstL
> >>              property name: xsd:string [1]
> >>          subclass ConstW
> >>              property iri: xsd:anyURI
> >>          subclass ConstD
> >>              property lex: xsd:string
> >>              property type: xsd:anyURI
> >> ]]]
> >>
> >> In practice it would be nice to identify the subclasses by context 
> >> rather than explicit class labels so, abusing asn06 notation, an 
> >> alternative might be:
> >>
> >> [[[
> >> class TERM
> >>      subclass Const
> >>          subclass CONSTL
> >>              property name: xsd:string
> >>          subclass CONSTW
> >>              property iri: xsd:anyURI
> >>          subclass CONSTD
> >>              property lex: xsd:string
> >>              property type: xsd:anyURI
> >> ]]]
> >>
> >> For the fully striped XML syntax this would imply:
> >>
> >>      <Const><name>USD</name></Const>
> >>      <Const><iri>http://example.com/ISO4217/usd</iri></Const>
> >>      <Const><lex>42</lex><type>http://www.w3.org/2001/XMLSchema#int
> >>                    </type></Const>
> >>
> >> For a prettified XML syntax this might imply something like:
> >>
> >>      <Const rif:name="USD" />
> >>      <Const rif:iri="http://example.com/ISO4217/usd" />
> >>      <Const xsi:type="xsd:int">42</Const>
> >>
> >> For the human readable syntax this might be:
> >>
> >>      USD
> >>      <http://example.com/ISO4217/usd>
> >>      "42"^^xsd:int or 42
> >>
> >> ** XMLLiteral
> >>
> >> To improve RDF compatibility I think we also need the datatype 
> >> rdf:XMLLiteral to be added to the list of datatypes for this dialect 
> >> (and the core).
> >>
> >> ** Presentational: separation of abstract, human-readable and XML syntax
> >>
> >> Currently the sub-section "Syntax for Primitive Types" comes as part of 
> >> the "Concrete syntax" section but it covers more than that including 
> >> subtype relationships.
> >>
> >> I'd be inclined to split that section up. Put the discussion on the 
> >> value spaces and subtype relationships in the earlier section "Primitive 
> >> data types" and put the discussion on human readable and XML concrete 
> >> syntax in their respective sub-sections.
> >>
> >> If you would rather keep the material together then perhaps at least 
> >> raise it one level up the section hierarchy.
> >>
> >> ** Presentational: degree of tie in to XML Schema datatypes
> >>
> >> The semantics section currently says:
> >>
> >> [[[
> >> Interpretation of primitive data types. We now explain how primitive 
> >> data types are integrated into the semantics of the basic RIF logic.
> >>
> >> The XML Schema Part 2: Datatypes specification defines the value space 
> >> for each XML data type, including the data types such as xsd:decimal, 
> >> which are of interest to RIF. The value space is different from the 
> >> so-called lexical space. Lexical space refers to the syntax of the 
> >> constant symbols that belong to a particular primitive data type. For 
> >> instance, "1.2"^^xsd:decimal and "1.20"^^xsd:decimal are two different 
> >> constants in RIF and in the lexical space of the XML data types. 
> >> However, these two constants are interpreted by the same element of the 
> >> value space of the xsd:decimal type.
> >>
> >> Formally, each of the XML data types supported by RIF comes with a value 
> >> space, denoted by Dtype (for instance, Dxsd:decimal), and a mapping, IC: 
> >> Consttype → Dtype. These value spaces and the corresponding mappings are 
> >> defined by the XML Schema Part 2: Datatypes specification.
> >> ]]]
> >>
> >> Whilst that's OK the phrasing ties the discussion of the nature of 
> >> datatypes specifically to XML Schema whereas we want dialects to be able 
> >> to define other datatypes and even for this dialect I think we also need 
> >> rdf:XMLLiteral.
> >>
> >> How about phrasing it like this:
> >>
> >> [[[
> >> Interpretation of primitive data types. We now explain how primitive 
> >> data types are integrated into the semantics of the basic RIF logic.
> >>
> >> Each primitive datatype _type_ is defined by four components:
> >>    1. a non-empty set of character strings called the lexical space of d;
> >>    2. a non-empty set called the value space of d, denoted by D_type_
> >>    3. a mapping from the lexical space of d to the value space of d
> >>       IC: Const_type_ → D_type_
> >>    4. an IRI which identifies the datatype.
> >>
> >> In the case of the datatypes xsd:long, xsd:string, xsd:decimal, 
> >> xsd:time, xsd:dateTime then the lexical space, value space, lexical to 
> >> value mapping and identifying IRI of each are defined by the XML Schema 
> >> Part 2: Datatypes specification [XSD].
> >>
> >> Note that lexical space refers to the syntax of the constant symbols 
> >> that belong to a particular primitive data type. For instance, 
> >> "1.2"^^xsd:decimal and "1.20"^^xsd:decimal are two different constants 
> >> in RIF and in the lexical space of the XML data types. However, these 
> >> two constants are interpreted by the same element of the value space of 
> >> the xsd:decimal type.
> >>
> >> In the case of the datatype rdf:XMLLiteral then the lexical space, value 
> >> space, lexical to value mapping and identifying IRI are all defined by 
> >> the RDF Concepts specification [XML-LITERAL].
> >>
> >> [XSD] http://www.w3.org/TR/xmlschema-2/
> >>
> >> [XML-LITERAL] http://www.w3.org/TR/rdf-concepts/#dfn-rdf-XMLLiteral
> >> ]]]
> >>
> >> ** Presentational: trivial quibble
> >>
> >> In the subsection "Syntax for Primitive Types" it says:
> >>
> >> [[[
> >> The part of such symbols that occurs inside the double quotes is called 
> >> a _literal_ of the symbol.
> >> ]]]
> >>
> >> could we use _lexical form_ (or something similar) instead of _literal_ 
> >> there? That would tie in with the later semantics section and would 
> >> avoid further overloading of the name literal.
> >>
> >>
> >> Hope this helps somewhat.
> >>
> >> Dave
> >>
> >> [1] Minor footnote: for the "name" property of ConstL I've left it as an 
> >> xsd:string, however the current concrete human readable syntax will not 
> >> work with unconstrained strings as const names (it implicitly expects 
> >> names to have no spaces and no punctuation like '(' and ')', we should 
> >> either constrain the abstract syntax, extend the concrete syntax, or 
> >> point out that the concrete human-readable syntax cannot carry all legal 
> >> instance documents.
> >>
> >> At some point we should review the human readable syntax, it is not yet 
> >> fully specified. However, it seems like a low priority (compared to the 
> >> abstract syntax, semantics and concrete XML syntax) which is why this 
> >> comment is relegated to a footnote.
> >>
> >> -- 
> >> Hewlett-Packard Limited
> >> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> >> Registered No: 690597 England
> >>
> > 
> > 
> > 
> 
>

Received on Tuesday, 24 July 2007 15:49:52 UTC