<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.26 (Ruby 2.6.3) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>

<?rfc docmapping="yes"?>

<rfc ipr="trust200902" docName="draft-hong-asdf-sdf-nonaffordance-00" category="std" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="SDF Extension for Non-Affordance Info">Semantic Definition Format (SDF) Extension for Non-Affordance Information</title>
    <seriesInfo name="Internet-Draft" value="draft-hong-asdf-sdf-nonaffordance-00"/>

    <author fullname="Jungha Hong" role="editor" initials="J." surname="Hong">
      <organization abbrev="ETRI">Electronics and Telecommunications Research Institute</organization>
      <address>
          <postal>
              <street>218 Gajeong-ro, Yuseong-gu</street>
              <city>Daejeon</city>
              <region></region>
              <code>34129</code>
              <country>South Korea</country>
          </postal>
          <phone>+82 42 860 0926</phone>
          <email>jhong@etri.re.kr</email>
      </address>
    </author>
    <author fullname="Hyunjeong Lee" initials="H." surname="Lee">
        <organization abbrev="ETRI">Electronics and Telecommunications Research Institute</organization>
        <address>
            <postal>
                <street>218 Gajeong-ro, Yuseong-gu</street>
                <city>Daejeon</city>
                <region></region>
                <code>34129</code>
                <country>South Korea</country>
            </postal>
            <phone>+82 42 860 1213</phone>
            <email>hjlee294@etri.re.kr</email>
        </address>
    </author>

  <area>ART</area>
  <workgroup>ASDF</workgroup>
  <keyword>Internet-Draft</keyword>
  <abstract>
    <t>
      This document describes an extension to the Semantic Definition Format (SDF)
      for representing non-affordance information of Things, such as physical,
      contextual, and descriptive metadata. This extension introduces a new
      class, sdfNonAffordance, that enables comprehensive modeling of
      Things and improves semantic clarity.
    </t>
  </abstract>
</front>

<middle>
    <!--section 1-->
    <section title="Introduction">
      <t>
        The Semantic Definition Format (SDF) has been instrumental in
        standardizing the representation of affordances - properties, actions,
        and events - of Things <xref target="I-D.ietf-asdf-sdf"/>.
        However, there exists a gap in representing
        non-affordance information, such as location, contextual
        metadata, and other descriptive elements that do not directly pertain
        to device interactions. Addressing this gap is crucial for comprehensive
        device modeling, especially in applications like digital twins where
        holistic representations are essential.
      </t>

      <t>
        This document describes a framework to extend the SDF by incorporating
        non-affordance information. Integrating these extensions allows SDF to
        provide a more comprehensive representation of Things, thereby enhancing
        semantic descriptions.
	    </t>
    </section>
     <!--section 1-->

     <!--section 2-->
    <section anchor="terminology">
      <name>Terminology and Conventions</name>

      <t>
        The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
      "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
      "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
    </t>

    <t>
      <list style="symbols">
        <t>
         Non-Affordance:
        attributes of a Thing that are not directly related to its interactive
        capabilities. This includes descriptive metadata such as location,
        manufacturer details, and other contextual information.
       </t>
     </list>
   </t>

    </section>
    <!--section 2-->

    <!--section 3-->
    <section title="Motivation and Use Cases">
     <t>
      The integration of non-affordance information into the Semantic Definition
      Format (SDF) addresses several critical needs in the modeling of Internet
      of Things (IoT) devices. The key motivations and corresponding use cases
      in the following subsections illustrate the importance of this extension:
    </t>

    <section title="Motivation">
     <t>
       In the current SDF framework, the primary focus is on defining
       affordances - interactive elements such as Properties, Actions, and Events.
       While this approach effectively captures the interactive capabilities of
       a Thing, it overlooks essential non-interactive attributes that are vital
       for a comprehensive device representation. These non-affordance attributes
       encompass contextual information and descriptive metadata, including dimensions,
       weight, location, manufacturer details, and operational constraints.
       The absence of standardized representation for such information can lead
       to fragmented device models, hindering interoperability and the seamless
       integration of devices across diverse IoT ecosystems.
     </t>
   </section>

   <section title="Use Cases">
    <t>
      3.2.1.	Asset Management and Tracking
    </t>
    <t>
      <list style="symbols">
        <t> Scenario: A logistics company utilizes IoT-enabled containers equipped
            with sensors to monitor shipments.</t>
        <t> Requirement: To effectively manage and track these assets, it's crucial
            to have standardized data on each container's physical dimensions,
            weight capacity, and current location.</t>
        <t> Solution: Incorporating non-affordance information into SDF allows
            for the uniform representation of these attributes, facilitating
            efficient asset tracking, optimizing load planning, and ensuring
            compliance with transportation regulations.</t>
      </list>
    </t>

    <t>
      3.2.2.	Environmental Context Awareness
    </t>
    <t>
      <list style="symbols">
        <t> Scenario: A smart building management system integrates various
            sensors and devices to monitor and control environmental conditions. </t>
        <t> Requirement: Understanding the installation environment of each device,
            such as room location, mounting position, and surrounding materials,
            is essential for accurate data interpretation and optimal system performance. </t>
        <t> Solution: By extending SDF to include environmental context as
            non-affordance information, the system can dynamically adjust operations
            based on device placement and environmental factors, enhancing occupant
            comfort and energy efficiency. </t>
      </list>
    </t>

    <t>
      3.2.3.	Regulatory Compliance and Certification
    </t>
    <t>
      <list style="symbols">
        <t> Scenario: Medical devices deployed in healthcare facilities must
            adhere to stringent regulatory standards and certifications. </t>
        <t> Requirement: Detailed documentation of each device's manufacturer,
            model number, serial number, and certification information is necessary
            for compliance audits and maintenance schedules. </t>
        <t> Solution: Embedding this non-affordance information within SDF ensures
            that all relevant metadata is consistently available, simplifying compliance
            reporting and facilitating timely maintenance and recalls when necessary. </t>
      </list>
    </t>

    <t>
      By integrating non-affordance information into SDF, these use cases demonstrate
      how a more holistic device model enhances interoperability, operational efficiency,
      and compliance across various IoT applications.
    </t>
  </section>

    </section>
    <!--section 3-->

    <!--section 4-->
    <section title="SDF Extension for Non-Affordance Information">

      <section title="Concept">
       <t>
         In the SDF, the primary focus has been on
         defining affordances - interactive elements such as Properties, Actions,
         and Events - that specify how external entities can interact with a Thing.
         However, to achieve a more comprehensive representation of a Thing,
         it's essential to include non-affordance information, which encompasses
         attributes not directly related to interaction but crucial for understanding
         the Thing's context and characteristics.
      </t>
      <t>
        To address this need, we propose introducing a new class named sdfNonAffordance
        within the SDF architecture. This class allows for the inclusion of metadata
        such as physical dimensions, location, environmental context, and manufacturer details.
      </t>
     </section>

     <section title="Syntax and Semantics">
      <t>
        The sdfNonAffordance is defined with attributes such as:
      </t>
      <t>
        <list style="symbols">
          <t> name: Identifier for the non-affordance attribute. </t>
          <t> description: Textual explanation of the attribute. </t>
          <t> type: Data type (e.g., string, number, object, boolean, array) of the attribute value. </t>
          <t> unit: Applicable measurement unit, if relevant. </t>
        </list>
      </t>

      <figure anchor="structure">
        <name>Structure of sdfNonAffordance in SDF</name>
        <sourcecode>
          {
           "sdfObject": {
              "device": {
                  "sdfNonAffordance": {
                      "attribute-name": {
                          "description": "Attribute description",
                          "type": "data type",
                          "unit": "unit if applicable"
                  }
                }
              }
            }
          }
        </sourcecode>
      </figure>

      <t> This structure ensures clarity and consistency in representing non-affordance information. </t>

    </section> <!--section 3-->



    <!--section 4-->
    <section title="Examples">

      <t> 4.3.1. Geospatial information </t>

      <figure anchor="example1">
        <name>Example of geospatial information</name>
        <sourcecode>
          {
           "sdfObject": {
              "tracker-device": {
                  "sdfNonAffordance": {
                      "location": {
                          "description": "Geographical coordinates",
                          "type": "object",
                          "wgs84": {
                              "latitude": 60.1676,
                              "longitude": 24.9514
                    }
                  }
                }
              }
            }
          }
        </sourcecode>
      </figure>

      <t> 4.3.2. TBD </t>
      <t> 4.3.3. TBD </t>

    </section>

  </section>
  <!--section 4-->

   <!--section 5-->
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t> TBD </t>
    </section>
    <!--section 5-->

    <!--section 6-->
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t> TBD </t>
    </section>
    <!--section 6-->

  </middle>

  <back>
  <!--section 7-->
  <references title='Normative References'>


        <!--&id.draft-ietf-asdf-sdf;-->


      <!--  &id.draft-laari-asdf-relations;-->


        <reference anchor='RFC2119'>
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname='S. Bradner' initials='S.' surname='Bradner'/>
            <date month='March' year='1997'/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.
      				  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.
      				  This document specifies an Internet Best Current Practices for the Internet Community,
                and requests discussion and suggestions for improvements.
              </t>
            </abstract>
          </front>
          <seriesInfo name='BCP' value='14'/>
          <seriesInfo name='RFC' value='2119'/>
          <seriesInfo name='DOI' value='10.17487/RFC2119'/>
        </reference>

        <reference anchor='RFC8174'>
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname='B. Leiba' initials='B.' surname='Leiba'/>
            <date month='May' year='2017'/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications.
				  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name='BCP' value='14'/>
          <seriesInfo name='RFC' value='8174'/>
          <seriesInfo name='DOI' value='10.17487/RFC8174'/>
         </reference>

         <reference anchor='I-D.ietf-asdf-sdf'>
           <front>
             <title>Semantic Definition Format (SDF) for Data and Interactions of Things</title>
             <author fullname="Michael Koster" initials="M." surname="Koster">
               <organization>KTC Control AB</organization>
             </author>
             <author fullname="Carsten Bormann" initials="C." surname="Bormann">
               <organization>Universität Bremen TZI</organization>
             </author>
             <author fullname="Ari Keränen" initials="A." surname="Keränen">
               <organization>Ericsson</organization>
             </author>
             <date day="17" month="March" year="2025"/>
             <abstract>
               <t>The Semantic Definition Format (SDF) is concerned with Things, namely
                  physical objects that are available for interaction over a network.
                  SDF is a format for domain experts to use in the creation and
                  maintenance of data and interaction models that describe Things.  An
                  SDF specification describes definitions of SDF Objects/SDF Things and
                  their associated interactions (Events, Actions, Properties), as well
                  as the Data types for the information exchanged in those
                  interactions.  Tools convert this format to database formats and
                  other serializations as needed.

               </t>
             </abstract>
           </front>
           <seriesInfo name='Internet-Draft' value='draft-ietf-asdf-sdf-23'/>
         </reference>

  </references>
  <!--section 7-->

  </back>
</rfc>
