[semantics-public] representing DEF/USE information

Thu Nov 7 05:51:21 PST 2019

John, you've identified unfinished business in our design pattern for RDF/OWL representation of an X3D model. Thank you for close review. We never resolved this question.

Right now the relationship is only apparent from the names (:MaterialLightBlue and :MaterialLightBlue-USE-1) which are informational for people and not a basis for inference.  Am expecting that the provided naming pattern for DEF/USE/other nodes is simply syntactic sugar provided during by X3dToTurtle.xslt conversion, not something we would require in a specification design.

Adding "owl:sameAs :MaterialLightBlue ; # USE" to :MaterialLightBlue-USE-1  (as part of X3dToTurtle.xslt conversion) appears to be needed.  Or perhaps something else, as considered in our prior emails below.

Another omission: not finding the DEF name included in the triples.  That is part of the original model and not information that should be lost.  Perhaps adding "rdfs:label :MaterialLightBlue ; # DEF" to :MaterialLightBlue is also needed.  We should look at other uses of RDF/OWL and see how they handle representations of ID information.

Next step: what would relevant questions be regarding DEF and USE nodes be that would utilize this relationship?  Perhaps hasDEF hasUSE isUSE properties, or inferences? These can inform writing some queries and seeing if the owl:sameAs relationship works OK.  Those steps are still needed.

Further consideration and experimentation will be helpful, this information is pretty central and we want to get it right.

Relevant triples from HelloWorld.ttl
https://www.web3d.org/x3d/content/semantics/examples/HelloWorld.ttl
=====================================
:Appearance_2_2_2_1_2 a owl:NamedIndividual, x3do:Appearance ;
   x3do:hasParent :Shape_2_2_2_1 ;
   x3do:hasMaterial :MaterialLightBlue ;
   x3do:hasTexture :ImageCloudlessEarth .
:MaterialLightBlue a owl:NamedIndividual, x3do:Material ;
   x3do:hasParent :Appearance_2_2_2_1_2 ;
   x3do:diffuseColor '0.1 0.5 1' .

:Appearance_2_2_3_1_2 a owl:NamedIndividual, x3do:Appearance ;
   x3do:hasParent :Shape_2_2_3_1 ;
   x3do:hasMaterial :MaterialLightBlue-USE-1 .
:MaterialLightBlue-USE-1 a owl:NamedIndividual, x3do:Material ;
   x3do:hasParent :Appearance_2_2_3_1_2 .
=====================================

Relevant specification clause:
https://www.w3.org/TR/owl-ref/#sameAs-def
=========================================
5.2.1 owl:sameAs

The built-in OWL property owl:sameAs links an individual to an individual. Such an owl:sameAs statement indicates that two URI references actually refer to the same thing: the individuals have the same "identity".

For individuals such as "people" this notion is relatively easy to understand. For example, we could state that the following two URI references actually refer to the same person:

<rdf:Description rdf:about="#William_Jefferson_Clinton">
   <owl:sameAs rdf:resource="#BillClinton"/>
</rdf:Description>

The owl:sameAs statements are often used in defining mappings between ontologies. It is unrealistic to assume everybody will use the same name to refer to individuals. That would require some grand design, which is contrary to the spirit of the web.

In OWL Full, where a class can be treated as instances of (meta)classes, we can use the owl:sameAs construct to define class equality, thus indicating that two concepts have the same intensional meaning. An example:

<owl:Class rdf:ID="FootballTeam">
   <owl:sameAs rdf:resource="http://sports.org/US#SoccerTeam"/>
</owl:Class>

One could imagine this axiom to be part of a European sports ontology. The two classes are treated here as individuals, in this case as instances of the class owl:Class. This allows us to state that the class FootballTeam in some European sports ontology denotes the same concept as the class SoccerTeam in some American sports ontology. Note the difference with the statement:

<footballTeam owl:equivalentClass us:soccerTeam />

which states that the two classes have the same class extension, but are not (necessarily) the same concepts.

NOTE: For details of comparison of URI references, see the section on RDF URI references in the RDF Concepts document [RDF Concepts].
=========================================

On 11/2/2019 7:44 PM, John Carlson wrote:
> Aha, ignore previous email, I found this.  It would seem if we had multiple sameAs it would be confusing semantically?  Not really sure.
> 
> 5. *Improved DEF/USE representation possibilities*
> 
> /Next question/. Wondering: when we define nodes that have a DEF or USE, should we also define owl:sameAs for the regular naming convention of individuals that indicates graph position in the original scene graph?
> 
> For example, current form
> 
> :ViewUpClose a owl:NamedIndividual, x3do:Viewpoint ; # current
> 
>     x3do:hasParent :Group_2_2 ;
> 
>     x3do:centerOfRotation "0 -1 0" ;
> 
>     x3do:description "Hello world!" ;
> 
>     x3do:position "0 -1 7" .
> 
> would become
> 
> :Viewpoint_2_2_1 a owl:NamedIndividual, x3do:Viewpoint ; # proposed
> 
>     owl:sameAs :ViewUpClose ; # DEF
> 
>     x3do:hasParent :Group_2_2 ;
> 
>     x3do:centerOfRotation "0 -1 0" ;
> 
>     x3do:description "Hello world!" ;
> 
>     x3do:position "0 -1 7" .
> 
> Similarly considering USE nodes, we might further elaborate these relationships by describing equivalence of numbered-label with USE name and with original DEF node...  Current form:
> 
> :MaterialLightBlue a owl:NamedIndividual, x3do:Material ; # current
> 
>     x3do:hasParent :Appearance_2_2_2_1_2 ;
> 
>     x3do:diffuseColor "0.1 0.5 1" .
> 
> would become:
> 
> :Material_2_2_3_1_2_1 a owl:NamedIndividual, x3do:Material ; # proposed
> 
>     owl:sameAs :MaterialLightBlue ; # USE
> 
>     owl:sameAs :MaterialLightBlue-USE-1 ; # USE
> 
>     x3do:hasParent :Appearance_2_2_3_1_2 .
> 
> However, if we are going to call them owl:sameAs, they might not be sufficiently distinguished from the original DEF.  Perhaps subclassOf is a better relationship?
> 
> Please consider.  I will apply next pattern to all examples for further testing.

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