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.

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

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.

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 13:40:20 UTC