Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [Fwd: [802.21] We MUST improve the use and readability of the new commentary tool]

Title:
Thanks Yoshihiro:

Your comments 13, 15: "The Basic Schema Representation in ASN.1 is not useful unless a schema-based query  is defined for it." Are you objecting to ASN.1 representation or the proper schema format for it?

Is comment 17 empty?

Peretz Feder
On 9/19/2005 6:47 PM, Peretz Feder wrote:


Subject:
Re: [802.21] We MUST improve the use and readability of the new commentary tool
From:
Yoshihiro Ohba <yohba@tari.toshiba.com>
Date:
Mon, 19 Sep 2005 11:43:24 -0400
To:
Peretz Feder <pfeder@lucent.com>		 

Peretz and all,

The reasons for my comments 120, 122, 123 and 129 were in fact
described in my original submission D00-02_Ohba_Yoshihiro.USR which is
attached to this email.  I don't know why they are missing in the
D00-02_MasterFile.USR file.  For your convenience, let me also attach
.htm file that was exported from my original .USR file and contains
the same information but with easier view.  You will see all the
"reason" fields are filled in those files except for the empty
comment.  Regarding the empty comment, it was always automatically
generated when I export my original .USR file to the final submission
version by pushing "(2) Save Data to File" button in "Create and
Submit Ballot" view, and I was not able to suppress generation of the
empty comment.  Is it a bug of the tool or is my usage wrong?

Best regards,

Yoshihiro Ohba


On Mon, Sep 19, 2005 at 02:30:03AM -0400, Peretz Feder wrote:
  
Yoshihiro comment 120: Why remove table 6?
Yoshihiro comment 122: why remove figure 22?
Yoshihiro comment 123: why remove table 7?
Yoshihiro comment 129, 130: Why remove annex C.2, C.3, C.4?
Yoshihiro comment 133: empty comment


Commentary Version ExportDate VoterBallotNumber VoterDocNumber VoterFirstName VoterLastName VoterEmail VoterPhone VoterStatus Vote Comment Type Starting Page Number Starting Line Number Section Change Reason FigTabNumber
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 41 20 6.3.2 Replace text between lines 20 and 44 of page 41 with the following:

"
The information elements provided by the Information Service can be classified into two categories:

1) Media-Independent Information (MII): These information elements describe the media-independent properties of the network. MII includes of Point of Attachment, Neighboring Networks, Neighboring PoAs, Location of PoA, Network Operator, Roaming Partners, Cost, Higher Layer Security Support, and Higher Layer QoS Support .

2) Media-Dependent Information (MDI): These information elements describe the information related to link and physical layers. MDI includes of Data Rate, MAC Type, PHY Type, Link Layer Security, and Link Layer QoS .

Each information element in MII and MDI belongs to one of the following two sets, e.g, , the basic set and the extended set. Information elements in the basic set must be supported by all MIH entities. Support for information elements in the extended set is optional.

Tables 4 and 5 describe a set of information elements in both categories that include the basic and extended set. When new information elements are added to MII or MDI, they need to be most likely defined in the extended set.

Information elements may be obtained via a PoA before the STA authenticates to the PoA irrespective of whether they belong to the basic or extended set. While all of the above information elements are necessary and will be available via 802.21 information service framework, it is important to note that MDI will be mostly directly available via media specific technologies. In cases where media specific amendments are not available or possible, information elements in MDI can be carried over via higher layer transport.
"		 - General Network Information (GNI) and Higher Layer Information (HLI) should be merged into
"Media-Independent Information (MDI)". Link Layer Information (LLI) should be renamed to "Media-dependent Information (MII)".

- Tables 4, 5 and 6 should be reduced into two tables of MDI and MII, and revised with more detailed description.

- Definition of basic set and extended set needs to be clearly described in this section.
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 41 49 6.3.2 Replace Table 4 with the one described in Section 2.1 of 21-05-0346-0000_Supplement_D00-02_Ohba_Yoshihiro.doc. - Media Types column is not meaningful. The Media Types column should be replaced with another column that indicates whether a given information element belongs to basic set or extended set.

- "List of networks available" should be renamed to a less confusing name.

- "Network standards supported" is ambiguous and should be removed.

- "Network identifier" is similar to "Operator" and should be removed.

- "Operator" needs to have not only a name but also a unique identifier.

- "IP Version" is not useful information and should be removed from MII.

- "SLAList" information is ambiguous and should be removed.

- "neighbor information" contain only static and limited information such as a list of neighboring PoAs. Also it should be replaced to more specific name like "neighboring PoAs".

- "AccessRouterInfo" is too detailed to be defined in the basic set.

- More detailed description and comments are needed for each information elements. 		Table 4
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 42 39 6.3.2 Replace Table 5 with the one described in Section 2.2 of 21-05-0346-0000_Supplement_D00-02_Ohba_Yoshihiro.doc. - Media Types column is not meaningful. The Media Types column should be replaced with another column that indicates whether a given information element belongs to basic set or extended set.

- "Neighbor information" can contain MII and MDI, and can be obtained by querying the basic set and extended set of each PoA in the "neighboring PoAs" information element in MII. Thus, this is redundant and should be removed from MDI.

- "AccessRouterInfo" is not MDI and should be removed.

- More detailed description and comments are needed for each information elements.
 Table 5
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 43 6 6.3.2 Remove Table 6. - Since GNI and HLI are merged into MII, this table for HLI is not needed anymore. Table 6
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 43 42 6.3.2 Replace the text with:

"
MIHF entity (e.g., a STA or network entity) can extract the information elements in the basic set and the extended set either from media specific broadcast information or by sending a specific request/response primitive. On the other hand, before sending a request/response, the MIHF entity should have the knowledge that the network supports the 802.21 MIH standard (e.g., via a management frame that carries capability information). For example, MIHF entity in STA may request the MIHF entity of PoA for such information. It is important to note that before a STA is authenticated to the PoA and ready to exchange data, it should be able to obtain all the information elements listed in Tables 4, 5 and 6. These information elements may then be used by the STA's handover function to determine the right PoA to attach.
"		 - The text can be described without referring Table 7 (which is refereed incorrectly to as Table 8.3) and Figure 22.

- The text should be revised that information elements in both the basic set and extended set can be obtained either
from media-specific broadcast information or by sending a specific request/response primitive.
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 44
6.3.2 Remove Figure 22. Figure 22 is not useful. Figure 22
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 45 1 6.3.2 - Remove Table 7

- Remove text starting from line 39 of page 45 and ending at line 23 of page 46.		 Table 7 is just informative and should not be included in this section. Table 7
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 46 58 6.3.3.1 Insert the following text at line 58 of page 46:

"
In order to strictly define each information element in an RDF schema, the schema is augmented with Web Ontology language (OWL) [OWL].
OWL is a Web Ontology language. OWL uses both URIs for naming and the description framework provided by RDF to add the following capabilities to ontologies:
- Ability to be distributed across many systems
- Scalability
- Compatibility with other Web standards for accessibility and internationalization
- Openness and extensibility

OWL builds on RDF and RDF Schema and adds more vocabulary for describing properties and classes: among others, relations between classes (e.g. disjoint-ness), carnality (e.g. "exactly one"), equality, richer typing of properties and characteristics of properties (e.g. symmetry), and enumerated classes.
"		 Since the basic schema uses OWL in addition to RDF Schema, a brief description about OWL needs to be added.
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 46 59 6.3.3.1 Replace the two paragraphs starting at line 1 of page 47 with:

"
As described earlier, the RDF schema definition for MIIS consists of two parts; the basic and the extended
schema. The basic schema is not supposed to be updated. An MIH entity is typically pre-provisioned with
the basic schema for ease of implementation of schema-based query. In scenarios where the basic schema is not pre-provisioned methods such as DHCP may be used to access the URL of the basic schema.

Unlike the basic schema, the extended schema is expected to be updated periodically, e.g., when a new link layer technology is introduced. The extended schema can be retrieved from the specified URL via the IEEE
802.21 information service using the schema query capability described in Section 8.5.3 without any reprovision of such extended schema. The URL of the extended schema can also be obtained via the schema
URL query capability described in section 8.5.3. Alternatively DHCP may be used for finding out the URL of extended schema. The extended schema is defined as an extension of the basic schema and includes data structure and relationship of media-specific or higher-layer information. In that sense extended schema is the complement of basic schema. An extended schema may be automatically generated from various of media-specific or higher-layer MIB definitions such as 802.11 MIB, 802.16 MIB and TCP/IP MIB-II.

Figure 8-3 below shows an example graphical representation of the 802.21 MIIS basic schema in which 'Network' 'MII', 'MDI', 'PoA', 'NAS-Port-Type', 'Location', 'Operator', 'Cost' , 'Geo-Coordinate' and 'Enterprise-Number' are represented as class, while all others are properties of classes. The lines indicate either the range or domain of a property or a sub class of a class. In particular 'r' represents the range of a property and 'd' represents domain of a property. 'Domain' defines the class that a particular property belongs to and 'range' defines a type of a particular property.
"		 - Some description is needed as to how extended schema can be created.

- Use of DNS query for finding the FQDN part of the location of the extended schema is not useful because it does not tell the entire URL of the extended schema. Instead, use of DHCP might be better to tell the URL of the extended schema.

- Since Figure 23 needs to be revised, the corresponding explanatory text in section 6.3.3.1 should be revised as well.
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 47
6.3.3.1 Replace Table 23 with the one described in Section 2.4 of 21-05-0346-0000_Supplement_D00-02_Ohba_Yoshihiro.doc. Figure 23 should be updated to be consistent with the revised basic set. Figure 23
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 89 27 7.4.14.3.1 Replace text starting at line 27 of page 89 and ending at line 42 of page 90 with:

"
A new InfoQueryFilter type "FILTER_INFO_DATA" is defined. When this InfoQueryFilter type is specified, the InfoQueryParameters must be a string which contains a SPARQL (Protocol and RDF Query language) query [2] where the SPARQL query is supposed to contain an appropriate query for obtaining expected RDF/XML data. The MIH_REPORT of the corresponding MIH_information.response must be a string which contains a SPARQL query result [3].

An example query request and response when FILTER_INFO_DATA is specified as InfoQueryFilter to obtain a list of poa-id's of neighboring 802.11 point of attachments (i.e., BSSIDs) at a given PoA is shown below.

QueryParameters:

PREFIX mihbase:<URL_TO_BE_ASSIGNED>
SELECT ?poa-id
WHERE {
?x1 mihbase:neighboring-poa ?x2 .
?x2 mihbase:poa-type 19 .
?x2 mihbase:poa-id ?poa-id .
?x1 mihbase:poa ?x3 .
?x3 mihbase:poa-type 19 .
?x3 mihbase:poa-id "001122334455" .
}

MIH_REPORT:

<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xsi:schemaLocation="http://www.w3.org/2001/sw/DataAccess/rf1/result2.xsd">

<head>
<variable name="poa-id"/>
</head>
<results>
<result>
<binding name="poa-id"><literal datatype="http://www.w3.org/2001/XMLSchema#hexBinary">aabbccddeeff</literal></binding>
</result>
<result>
<binding name="poa-id"><literal datatype="http://www.w3.org/2001/XMLSchema#hexBinary">001122334455</literal></binding>
<result>
</result>
<binding name="poa-id"><literal datatype="http://www.w3.org/2001/XMLSchema#hexBinary">0123456789ab</literal></binding>
<result>
</results>
</sparql>
"		 The schema-based query example should be updated to be consistent with the revised basic schema.
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 116 10 Annex C.1 Replace text starting at line 10 of page 116 and ending at line 44 of page 112 with:

"
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
<!ENTITY mihbase "URL_TO_BE_ASSIGNED">
<!ENTITY owl "http://www.w3.org/2002/07/owl#">
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
]>

<rdf:RDF xmlns:rdf="&rdf;" xmlns:rdfs="&rdfs;" xmlns:mihbase="&mihbase;"
xml:base="&mihbase;" xmlns:owl="&owl;" xmlns:xsd="&xsd;">

<owl:Ontology rdf:about="">
<rdfs:comment></rdfs:comment>
<rdfs:label>Basic Schema for IEEE 802.21 Information Service</rdfs:label>
</owl:Ontology>

<owl:Class rdf:ID="Cost">
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Free"/>
<owl:Thing rdf:about="#Non-Free"/>
</owl:oneOf>
</owl:Class>

<owl:Class rdf:ID="NAS-Port-Type">
<owl:equivalentClass rdf:resource="&xsd;unsignedShort"/>
<rdfs:comment>
This property contains a RADIUS NAS-Port-Type attribute value defined in
http://www.iana.org/assignments/radius-types.
</rdfs:comment>
</owl:Class>

<owl:Class rdf:ID="Enterprise-Number">
<owl:equivalentClass rdf:resource="&xsd;unsignedInt"/>
<rdfs:comment>
This property contains an SMI Network Management Private Enterprise Code defined in
http://www.iana.org/assignments/enterprise-numbers.
</rdfs:comment>
</owl:Class>

<owl:Class rdf:ID="Network">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#mii"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#mdi"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment>
Network class has two properties, namely mii for media-independent information and
mdi for media-dependent information.
A distinct instance of this class must be assigned for each point of attachment.
</rdfs:comment>
</owl:Class>

<owl:ObjectProperty rdf:ID="mii">
<rdf:type rdf:resource="&owl;InverseFunctionalProperty"/>
<rdfs:domain rdf:resource="#Network"/>
<rdfs:range rdf:resource="#Media-Independent-Information"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="mdi">
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Network"/>
<rdfs:range rdf:resource="#Media-Dependent-Information"/>
</owl:ObjectProperty>

<owl:Class rdf:ID="Media-Dependent-Information">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#data-rate"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment>
Media-Dependent-Information class has properties that are specific to link layer or lower.
The properties include data-rate.
Any property can be added to this class in an extended schema.
</rdfs:comment>
</owl:Class>

<owl:DatatypeProperty rdf:ID="data-rate">
<rdfs:label>Data Rate</rdfs:label>
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Media-Dependent-Information"/>
<rdfs:range rdf:resource="&xsd;unsignedInt"/>
<rdfs:comment>
The data-rate property contains a maximum data rate of the link layer of the PoA in unit of Kbps.
</rdfs:comment>
</owl:DatatypeProperty>

<owl:Class rdf:ID="Media-Independent-Information">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#poa"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#neighboring-network"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#neighboring-poa"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#location"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#location"/>
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#network-operator"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#network-operator"/>
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#cost"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#cost"/>
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#qos"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#qos"/>
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#security"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#security"/>
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>

<owl:ObjectProperty rdf:ID="poa">
<rdfs:label>PoA</rdfs:label>
<rdf:type rdf:resource="&owl;InverseFunctionalProperty" />
<rdfs:domain rdf:resource="#Media-Independent-Information"/>
<rdfs:range rdf:resource="#PoA"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="neighboring-network">
<rdfs:label>Neighboring Networks</rdfs:label>
<rdfs:domain rdf:resource="#Media-Independent-Information"/>
<rdfs:range rdf:resource="#NAS-Port-Type"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="neighboring-poa">
<rdfs:label>Neighboring PoAs</rdfs:label>
<rdfs:domain rdf:resource="#Media-Independent-Information"/>
<rdfs:range rdf:resource="#PoA"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="location">
<rdfs:label>Location of PoA</rdfs:label>
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Media-Independent-Information"/>
<rdfs:range rdf:resource="#Location"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="network-operator">
<rdfs:label>Network Operator</rdfs:label>
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Media-Independent-Information"/>
<rdfs:range rdf:resource="#Operator"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="roaming-parners">
<rdfs:label>Roaming Partners</rdfs:label>
<rdfs:domain rdf:resource="#Media-Independent-Information"/>
<rdfs:range rdf:resource="#Operator"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="cost">
<rdfs:label>Cost</rdfs:label>
<rdfs:domain rdf:resource="#Media-Independent-Information"/>
<rdfs:range rdf:resource="#Cost"/>
</owl:ObjectProperty>

<owl:DatatypeProperty rdf:ID="security">
<rdfs:label>Basic Higher Layer Characteristics</rdfs:label>
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Media-Independent-Information"/>
<rdfs:range rdf:resource="&xsd;boolean"/>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="uam">
<rdfs:label>UAM</rdfs:label>
<rdfs:subPropertyOf rdf:resource="#security"/>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="pana">
<rdfs:label>PANA</rdfs:label>
<rdfs:subPropertyOf rdf:resource="#security"/>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="qos">
<rdfs:label>Basic Higher Layer Characteristics</rdfs:label>
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Media-Independent-Information"/>
<rdfs:range rdf:resource="&xsd;boolean"/>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="diffserv">
<rdfs:label>Diffserv</rdfs:label>
<rdfs:subPropertyOf rdf:resource="#qos"/>
</owl:DatatypeProperty>

<owl:Class rdf:ID="Location">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#geo-coordinate"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#geo-coordinate"/>
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment>
This class has properties that indicate a location of PoA.
The properties include geo-coordinate. Any property can be added to this class
in an extended schema.
</rdfs:comment>
</owl:Class>

<owl:ObjectProperty rdf:ID="geo-coordinate">
<rdf:type rdf:resource="&owl;FunctionalProperty" />
<rdfs:domain rdf:resource="#Location"/>
<rdfs:range rdf:resource="#Geo-Coordinate"/>
</owl:ObjectProperty>

<owl:Class rdf:ID="Geo-Coordinate">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#lares"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#latitude"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#lores"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#longitude"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#at"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#altres"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#altitude"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#datum"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment>
This class has properties that represent geographic coordinate.
The format is based on the Location Configuration Information (LCI) defined in RFC 3825.
</rdfs:comment>
</owl:Class>

<owl:DatatypeProperty rdf:ID="lares">
<rdfs:domain rdf:resource="#Geo-Coordinate"/>
<rdfs:range rdf:parseType="Resource">
<xsd:Integer.minInclusive rdf:datatype="&xsd;Integer">0</xsd:Integer.minInclusive>
<xsd:Integer.maxInclusive rdf:datatype="&xsd;Integer">34</xsd:Integer.maxInclusive>
<rdfs:subClassOf rdf:resource="&xsd;Integer"/>
</rdfs:range>
<rdfs:comment>
This property contains the latitude resolution.
</rdfs:comment>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="latitude">
<rdfs:domain rdf:resource="#Geo-Coordinate"/>
<rdfs:range rdf:parseType="Resource">
<xsd:hexBinary.minInclusive rdf:datatype="&xsd;hexBinary">0</xsd:hexBinary.minInclusive>
<xsd:hexBinary.maxInclusive rdf:datatype="&xsd;hexBinary">3FFFFFFFF</xsd:hexBinary.maxInclusive>
<rdfs:subClassOf rdf:resource="&xsd;hexBinary"/>
</rdfs:range>
<rdfs:comment>
This property contains the integer part of latitude of the location.
</rdfs:comment>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="lores">
<rdfs:domain rdf:resource="#Geo-Coordinate"/>
<rdfs:range rdf:parseType="Resource">
<xsd:Integer.minInclusive rdf:datatype="&xsd;Integer">0</xsd:Integer.minInclusive>
<xsd:Integer.maxInclusive rdf:datatype="&xsd;Integer">34</xsd:Integer.maxInclusive>
<rdfs:subClassOf rdf:resource="&xsd;Integer"/>
</rdfs:range>
<rdfs:comment>
This property contains the longitude resolution.
</rdfs:comment>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="longitude">
<rdfs:domain rdf:resource="#Geo-Coordinate"/>
<rdfs:range rdf:parseType="Resource">
<xsd:hexBinary.minInclusive rdf:datatype="&xsd;hexBinary">0</xsd:hexBinary.minInclusive>
<xsd:hexBinary.maxInclusive rdf:datatype="&xsd;hexBinary">3FFFFFFFF</xsd:hexBinary.maxInclusive>
<rdfs:subClassOf rdf:resource="&xsd;hexBinary"/>
</rdfs:range>
<rdfs:comment>
This property contains the longitude of the location.
</rdfs:comment>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="at">
<rdfs:domain rdf:resource="#Geo-Coordinate"/>
<rdfs:range rdf:parseType="Resource">
<xsd:Integer.minInclusive rdf:datatype="&xsd;Integer">0</xsd:Integer.minInclusive>
<xsd:Integer.maxInclusive rdf:datatype="&xsd;Integer">2</xsd:Integer.maxInclusive>
<rdfs:subClassOf rdf:resource="&xsd;Integer"/>
</rdfs:range>
<rdfs:comment>
This property contains the altitude type.
</rdfs:comment>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="altres">
<rdfs:domain rdf:resource="#Geo-Coordinate"/>
<rdfs:range rdf:parseType="Resource">
<xsd:Integer.minInclusive rdf:datatype="&xsd;Integer">0</xsd:Integer.minInclusive>
<xsd:Integer.maxInclusive rdf:datatype="&xsd;Integer">30</xsd:Integer.maxInclusive>
<rdfs:subClassOf rdf:resource="&xsd;Integer"/>
</rdfs:range>
<rdfs:comment>
This property contains the altitude resolution.
</rdfs:comment>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="altitude">
<rdfs:domain rdf:resource="#Geo-Coordinate"/>
<rdfs:range rdf:parseType="Resource">
<xsd:hexBinary.minInclusive rdf:datatype="&xsd;hexBinary">0</xsd:hexBinary.minInclusive>
<xsd:hexBinary.maxInclusive rdf:datatype="&xsd;hexBinary">3FFFFFFF</xsd:hexBinary.maxInclusive>
<rdfs:subClassOf rdf:resource="&xsd;hexBinary"/>
</rdfs:range>
<rdfs:comment>
This property contains the altitude of the location.
</rdfs:comment>
</owl:DatatypeProperty>

<owl:DatatypeProperty rdf:ID="datum">
<rdfs:domain rdf:resource="#Geo-Coordinate"/>
<rdfs:range rdf:parseType="Resource">
<xsd:Integer.minInclusive rdf:datatype="&xsd;Integer">1</xsd:Integer.minInclusive>
<xsd:Integer.maxInclusive rdf:datatype="&xsd;Integer">2</xsd:Integer.maxInclusive>
<rdfs:subClassOf rdf:resource="&xsd;Integer"/>
</rdfs:range>
<rdfs:comment>
This property contains the datum type.
</rdfs:comment>
</owl:DatatypeProperty>

<owl:Class rdf:ID="PoA">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#poa-id"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#poa-type"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment>
This class has properties that represent a PoA. The properties are poa-type and poa-id.
</rdfs:comment>
</owl:Class>

<owl:ObjectProperty rdf:ID="poa-type">
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#PoA"/>
<rdfs:range rdf:resource="#NAS-Port-Type"/>
<rdfs:comment>
This property contains a RADIUS NAS-Port-Type attribute value defined in
http://www.iana.org/assignments/radius-types.
</rdfs:comment>
</owl:ObjectProperty>

<owl:DatatypeProperty rdf:ID="poa-id">
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#PoA"/>
<rdfs:range rdf:resource="&xsd;hexBinary"/>
<rdfs:comment>
This property contains a link-specific identifier of PoA.
</rdfs:comment>
</owl:DatatypeProperty>

<owl:Class rdf:ID="Operator">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#operator-id"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#operator-id"/>
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#operator-name"/>
<owl:cardinality rdf:datatype="&xsd;string">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment>
This class has properties that represent an operator.
The properties are operator-id and operator-name.
</rdfs:comment>
</owl:Class>

<owl:ObjectProperty rdf:ID="operator-id">
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Operator"/>
<rdfs:range rdf:resource="#Enterprise-Number"/>
</owl:ObjectProperty>

<owl:DatatypeProperty rdf:ID="operator-name">
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Operator"/>
<rdfs:range rdf:resource="&xsd;string"/>
<rdfs:comment>
This property contains the name of the operator.
</rdfs:comment>
</owl:DatatypeProperty>
</rdf:RDF>
"		 The basic schema definition should be updated.
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 122 48 Annex C.2 Remove Annex C.2 entirely. The Basic Schema Representation in ASN.1 is not useful unless a schema-based query is defined for it.
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 123 47 Annex C.3 Remove Annex C.3 entirely. The extended schema representation in RDF/XML can be automatically generated from various lower-layer and higher-layer MIB definitions, and does not need to be described in this document.
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 132 24 Annex C.4 Remove Annex C.4 entirely. The ASN.1 representation of extended schema is not needed as it is not tied with a schema-based query language and should be removed.
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member
Technical, Non-binding 87 20 7.4.14.1.2 - Remove text starting at line 20 of page 87 and ending at line 6 of page 88.

- Move the contents of Sections 7.4.14.3, 7.4.14.3.1, 7.4.14.3.2, 7.4.14.3.3 to Section 7.4.14.1.2.		 All QueryFilterTypes and its usage defined in this section are not well-defined. Since we have another set of QueryFilterTypes for schema-based query in 7.4.14.3, why do we need all these QueryFilterTypes for schema-less query?
1.55 2005/09/15
D00-02 Yoshihiro Ohba yohba@tari.toshiba.com 732-699-5305 Member