[x3d-public] X3D Semantic Web minutes: event-animation chains and representing accessType

Wed Apr 22 10:13:41 PDT 2020

Continuing with the examination of accessType.

The <field> element includes an attribute for accessType.  This is found in the ontology as an owl:toDataProperty with range SFString.

The X3DUOM includes enumerations for accessType: there are only 4 possible values.

       <SimpleType name="accessTypeChoices"
                   baseType="xs:NMTOKEN"
                   appinfo="accessTypeChoices are strictly allowed enumeration values for accessType. Prior names in VRML97 were eventIn, eventOut, field, exposedField respectively."
                   documentation="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#FieldSemantics">
          <enumeration value="initializeOnly"
                       appinfo="A field with accessType initializeOnly can be initialized, but cannot send or receive events."/>
          <enumeration value="inputOnly"
                       appinfo="A field with accessType inputOnly cannot be initialized or included in a scene file, but can receive input event values via a ROUTE."/>
          <enumeration value="outputOnly"
                       appinfo="A field with accessType outputOnly cannot be initialized or included in a scene file, but can send output event values via a ROUTE."/>
          <enumeration value="inputOutput"
                       appinfo="A field with accessType inputOutput can be initialized, and can also send or receive events."/>
       </SimpleType>

It would be good to get accessTypeChoices represented in X3D Ontology. We might then add other enumeration SimpleType defintions as well.)

We looked at

[1] OWL Web Ontology Language Reference: 6.2 Enumerated datatype
     https://www.w3.org/TR/owl-ref/#EnumeratedDatatype

"In addition to the RDF datatypes, OWL provides one additional construct for defining a range of data values, namely an enumerated datatype. This datatype format makes use of the owl:oneOf construct, that is also used for describing an enumerated class. In the case of an enumerated datatype, the subject of owl:oneOf is a blank node of class owl:DataRange and the object is a list of literals." etc.

"NOTE: Enumerated datatypes are not part of OWL Lite."

[2] PrimerExampleTurtle
     https://www.w3.org/2007/OWL/wiki/PrimerExampleTurtle

=================
# Emily
_:x35 rdf:type owl2:DataRange ;
     owl:oneOf ("39"^^xsd:integer "49"^^xsd:integer) .
=================

[3] Bob DuCharme's weblog, RDF lists and SPARQL
     http://www.snee.com/bobdc.blog/2014/04/rdf-lists-and-sparql.html

=================
d:myList d:contents ("one" "two" "three" "four" "five")
=================

So... first datatype property.

:accessTypeChoices rdf:type owl:DataRange ;
     owl:oneOf ("inputOutput","inputOnly","outputOnly","initializeOnly") .

This didn't work in Protege - more investigation needed.

Meanwhile we did find a useful refinement, replacing type :SFString with more-restricted type xsd:NMTOKEN as follows:

================================
:DEF a owl:DatatypeProperty ;
   rdfs:label "X3DNode field DEF is implemented by multiple nodes" ;
   rdfs:domain [ owl:unionOf ( :X3DNode # etc. long list of nodes and types
   rdfs:range :SFString .
================================
:DEF a owl:DatatypeProperty ;
   rdfs:label "X3DNode field DEF is implemented by multiple nodes" ;
   rdfs:domain [ owl:unionOf ( :X3DNode # etc. long list of nodes and types
   rdfs:range xsd:NMTOKEN .
================================

I will work on rippling this improvement throughout X3D Ontology.

Next step. Starting with Transform field 'translation' as defined in X3D Ontology:

:translation a owl:DatatypeProperty ;
   rdfs:domain :Transform ;
   rdfs:range :SFVec3f .

Jakub will look further on how datatype properties might be integrated, adding information to each field definition.

We meet again next Monday.

On 4/20/2020 10:38 AM, Don Brutzman wrote:
> Jakub and I had a useful meeting today.  We looked at X3D Ontology completeness to diagnose event animation chains.
> 
> A design pattern for representing animation chains is described in detail as part of the following chapter slideset.  Single-page checklist also attached as a convenience.
> 
> * X3D Graphics for Web Authors: Chapter 7, Event Animation Interpolation
>    http://x3dgraphics.com/slidesets/X3dForWebAuthors/Chapter07EventAnimationInterpolation.pdf
>    http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter07EventAnimationInterpolation/
> 
> slide 11.  "Event-animation design pattern. X3D can be imposing, there are many nodes. Nevertheless a simple design pattern is used for nearly every kind of animation.  his consistent event ROUTE pattern enables you to expertly animate most X3D scene behaviors."
> 
> * Event-animation design pattern:
>    Trigger node (optional) -> TimeSensor -> Interpolator/Sequencer/Script -> Target node's field
> 
> A 10-step algorithm for author creation of this design pattern is provided and has proven helpful.  Keeping a consistent pattern let's you avoid thinking that the various animation nodes are “really different” when they are not. It also helps you avoid skipping steps and making mistakes that are hard to debug afterwards.
> 
> Example diagram also attached that illustrates the following model.
> 
> * X3D Example Archives: X3D for Web Authors, Chapter 07 Event Animation Interpolation, Dolphin Morpher
>    https://x3dgraphics.com/examples/X3dForWebAuthors/Chapter07EventAnimationInterpolation/DolphinMorpherIndex.html
> 
> So, for X3D ontology, we want to see if we can write rules/queries to (a) illustrate event chains, and (b) diagnose whether any problems exist.
> 
> Example problems:
> - mismatched ROUTE DEF or field-name values
> - mismatched data types,
> - mismatched accessType values,
> - missing pieces.
> 
> So next step is to check X3D ontology for completeness of information provided.  As an example, let's look at Transform in X3D Ontology.  Excerpt:
> 
> http://www.web3d.org/specifications/X3dOntology4.0
> ##################################################
> :Transform a owl:Class ;
>    rdfs:subClassOf :X3DGroupingNode ;
>    rdfs:label "Transform is a Grouping node that can contain most nodes." .
> # bboxCenter field inheritedFrom=X3DGroupingNode with accessType=initializeOnly, type=SFVec3f, default=0 0 0
> # bboxSize field inheritedFrom=X3DGroupingNode with accessType=initializeOnly, type=SFVec3f, default=-1 -1 -1, baseType=bboxSizeType
> :center a owl:DatatypeProperty ;
>    rdfs:domain :Transform ;
>    rdfs:range :SFVec3f .
> # children field inheritedFrom=X3DGroupingNode with accessType=inputOutput, type=MFNode
> # displayBBox field inheritedFrom=X3DGroupingNode with accessType=inputOutput, type=SFBool, default=false
> :rotation a owl:DatatypeProperty ;
>    rdfs:domain :Transform ;
>    rdfs:range :SFRotation .
> :scale a owl:DatatypeProperty ;
>    rdfs:domain :Transform ;
>    rdfs:range :SFVec3f .
> :scaleOrientation a owl:DatatypeProperty ;
>    rdfs:domain :Transform ;
>    rdfs:range :SFRotation .
> :translation a owl:DatatypeProperty ;
>    rdfs:domain :Transform ;
>    rdfs:range :SFVec3f.
> ##################################################
> 
> So, our prior effort was not complete.  Looks like we need to come up with a proper representation for accessType and defaultValue field to achieve full expressive power in X3D Ontology that already exists in X3DUOM.
> 
>    rdfs:TBD1 accessType inputOutput;
>    rdfs:TBD2 defaultValue 0;
> 
> ... so that is how far we got.  More thinking and likely additions to to X3D Ontology will follow.
> 
> all the best, Don

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman