[semantics-public] representing DEF/USE information and path/order; ontology design patterns; X3D Semantic Web meeting minutes 18 NOV 2019

Brutzman, Donald (Don) (CIV) brutzman at nps.edu
Mon Nov 18 17:04:39 PST 2019


Your instincts are correct John... here is more detail.

The expressiveness of Turtle conversion of X3D scenes is nearly complete.  This is what round-tripping might confirm.

The real action to follow is in the queries, using SPARQL.  These are fairly rudimentary but nevertheless powerful.  We will be building them to broader and deeper effectiveness as we go.

	X3D Ontology for Semantic Web: Queries
	https://www.web3d.org/x3d/content/semantics/semantics.html#Queries

Recommended reading once you "get your head around" RDF/OWL:

	Bob Ducharme, Learning SPARQL, second edition, OReilly Media, Sebastopol, 2013.
	http://www.learningsparql.com

The queries there will continue to improve in coming months.  I'm looking forward to queries that include peeking into structured vocabularies with shapes and embedded MetadataSet information.  We have barely begun.   8)


On 11/18/2019 10:13 AM, yottzumm at gmail.com wrote:
> I think we need to decide whether or not the RDF/OWL/XML should be modified significantly after it’s been converted to Turtle.  That may help to guide what triples are used.  If we’re only doing querying and roundtripping, those are different use cases.  Perhaps we should generate different Turtle files for different use cases?
> 
> What do you think?
> 
> John
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
> 
> *From: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
> *Sent: *Monday, November 18, 2019 11:38 AM
> *To: *Jakub Flotyński <mailto:flotynski at kti.ue.poznan.pl>; X3D Semantic Web Working Group <mailto:semantics-public at web3d.org>
> *Subject: *Re: [semantics-public] representing DEF/USE information and path/order; ontology design patterns; X3D Semantic Web meeting minutes 18 NOV 2019
> 
> Thank you for explaining this message during today's teleconference meeting.
> 
> Very interesting discussion on today's X3D Semantic Web working group call.
> 
> On 11/13/2019 5:48 AM, Jakub Flotyński wrote:
> 
>  > I agree that the naming convention reflecting how an element is nested in the overall scene document (e.g., Viewpoint_2_2_1) can be useful to rebuild the primary X3D scene from a semantic X3D scene. However, if we decided to use RDF lists for arrays of values, e.g., coordinates, colors, translation, size, etc., maybe also element path in the scene document could be represented by an RDF list? The first number in the list can indicate the position of the element within its parent element, the second number - the position of the parent within the grandparent, and so on. For instance:
> 
>  >
> 
>  > instead of:
> 
>  >
> 
>  >             :Viewpoint_2_2_1 a owl:NamedIndividual, x3do:Viewpoint ; # proposed
> 
>  >
> 
>  > we will have:
> 
>  >
> 
>  >             :Viewpoint_2_2_1 a owl:NamedIndividual, x3do:Viewpoint ; # proposed
> 
>  >                             x3do:elementPath ( 1 2 2 ) .
> 
>  >
> 
>  > Even if the element identifier remains the same, there will be no additional property included in it, as now the path is. Thus, any unique identifier may be assigned to an element without losing the path. The path to the element within the scene document, which is worth a semantic representation, will have its own property. What do you think?
> 
>  >
> 
>  > Best regards
> 
>  > Jakub
> 
> 1. First point of agreement, that pseudo-DEF labels like ":Shape_2_2_1" cannot be reasoned upon per se, they are simply an ID literal.
> 
> ----
> 
> 2. Second point, for existing pattern, :Shape_2_2_1 means that, descending from X3D root (which is not counted), it is child 2 (Scene) then child 2 (Transform) then child 2 (Transform) then child 1 (un-DEF'ed Shape of interest).
> 
> This pattern is now properly documented on the X3D Ontology page.  More will appear there to document existing patterns in X3D Ontology and X3dToTurtle.xslt stylesheet conversion.
> 
>                  X3D Ontology: Design Patterns
> 
>                  https://www.web3d.org/x3d/content/semantics/semantics.html#DesignPatterns
> 
> ----
> 
> 3. Third, if we were to describe this path in the same order, it would be something like
> 
>                  x3do:elementPath ( 2 2 1 ) .
> 
> If we inverted it, it would be something like
> 
>                  x3do:elementPath ( 1 2 2 ) .
> 
> ----
> 
> 4.  It is of course questionable whether we want to do this at all.  Pros and cons:
> 
> a. such information can be partially reasoned via x3do:hasParent and x3do:hasChildren, which gives level in hierarchy but not order among peer elements.
> 
> b. Is exact order among peers needed for satisfactory reconstruction of the original scene graph?  In many cases order can be relaxed... but in some cases order is indeed critical.
> 
> - For example, children of Switch and LOD must appear in a certain order.
> 
> - Another example is DEF USE itself; USE must appear after DEF in a reconstructed scene graph.
> 
> - as ever, order is irrelevant in RDF/OWL turtle triples themselves.
> 
> c. This kind of path information is really hard to maintain in turtle if the scene graph itself is being modified.
> 
> d. The exact expression of the elementPath, if applied, should be consistent with the DEF/USE naming convention.
> 
> e. We might choose a pattern that is easily referencable via XPath to facilitate further queries.
> 
> ----
> 
> 5. An alternate approach might be to have a different property that gives order among children when such information is crucial to reconstructing the scene graph.  This minimalist approach might be sufficient to permit accurate reconstruction of a scene graph.  It is also much simpler to maintain, terser, and less error prone.
> 
> However the next step eliminates the need for approaches in paragraphs #4 and #5 above.
> 
> ----
> 
> 6. Yet another possibility for ordering of children is to create another rdf:list for child nodes, just as we do for numeric arrays.  For example, existing expression:
> 
> :Group_2_2 a owl:NamedIndividual, x3do:Group ;
> 
>     x3do:hasParent :Scene ;
> 
>     x3do:hasChildren :ViewUpClose, :TestWhitespaceCommas, :Transform_2_2_3 .
> 
> might become
> 
> :Group_2_2 a owl:NamedIndividual, x3do:Group ;
> 
>     x3do:hasParent :Scene ;
> 
>     x3do:hasChildren ( :ViewUpClose, :TestWhitespaceCommas, :Transform_2_2_3 ) .
> 
> This definitively provides order of children.  Simplest possible declaration syntax as well.  8)
> 
> Of interest is that x3do:hasParent is a pairwise relationship, and so the already-defined x3do:hasChild relation will still work without modification.  8)
> 
> We would need to create a change in ontology for MFNode children fields.  For example, Group node definition might need modification:
> 
> :hasChildren a owl:ObjectProperty ;
> 
>     rdfs:domain :field ;
> 
>     rdfs:range :X3DNode ;
> 
>     rdfs:subPropertyOf :hasChild .
> 
> We considered some possibilities, then continued...
> 
> ----
> 
> 7.  We found an omission in base type definitions - no type information is provided.  Existing version:
> 
> :MFColor rdf:type rdfs:Datatype ;
> 
>     rdfs:subClassOf :X3DField ;
> 
>     dc:description "MFColor specifies zero or more SFColor RGB triples" .
> 
> Jakub found the following example
> 
>                  http://eulersharp.sourceforge.net/2003/03swap/log-rules.html
> 
> and suggests constructs like
> 
> :hasChildren rdfs:range rdf:List
> 
> as well as, for field types,
> 
> :MFColor rdf:type rdfs:Class ;
> 
>     rdfs:subClassOf rdf:List;   # TODO what about float 3-tuple array?
> 
>     rdfs:subClassOf :X3DField ; # TODO confirm how to express both relationships
> 
>     dc:description "MFColor specifies zero or more SFColor RGB triples" .
> 
> TODO: Jakub will look at this set of relationships more closely for a precise resolution. This is needed for most of the X3D datatypes.
> 
> TODO: Don will then apply it in the implementation.
> 
> ----
> 
> 8. Important long-term TODO. A good SPARQL query to write will be one that can round-trip recreate the original scene graph.  This will provide positive confirmation (across all examples) that full representation has been achieved.  It is also an excellent design technique that has led to the successful definition of Java, JSON and other encodings/bindings for X3D.
> 
> ----
> 
> 9. Jakub and I have planned travel over the next few weeks.
> 
> Thanos we can each join you on different weeks if you want to look at book chapter further.
> 
> v/r Don
> 
>  > W dniu 07.11.2019 o 15:11, Jakub Flotyński pisze:
> 
>  >>
> 
>  >> I agree with the example:
> 
>  >>
> 
>  >> :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" ./
> 
>  >>
> 
>  >> If we have two different individuals in RDF we maintain the relationship to the original X3D document, especially if the naming convention with the numbers (e.g., _2_2_1) is respected. However, for every sameAs individuals, the properties should not be specified again (marked in red italics). Moreover, to reply to one of the questions below - subClassOf cannot be used here instead of sameAs, because subClassOf is for classes, not for individuals.
> 
>  >>
> 
>  >> Best regards
> 
>  >> Jakub
> 
>  >>
> 
>  >> W dniu 07.11.2019 o 14:51, Brutzman, Donald (Don) (CIV) pisze:
> 
>  >>> 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
> 
> 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
> 
> -- 
> 
> semantics-public mailing list
> 
> semantics-public at web3d.org
> 
> http://web3d.org/mailman/listinfo/semantics-public_web3d.org
> 


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


More information about the semantics-public mailing list