[semantics-public] representing DEF/USE information and path/order; ontology design patterns; X3D Semantic Web meeting minutes 18 NOV 2019
John Carlson
yottzumm at gmail.com
Mon Nov 18 22:26:20 PST 2019
Don, I think if we can generate turtle from SPARQL, all will be well. If
we are hand editing the turtle is where we might want to seek out a
different transformational output. In the long run, not when we’re
developing the first turtle and queries.
In other words, nothing in our automated test suit should require user
input.
On Mon, Nov 18, 2019 at 7:04 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/semantics-public_web3d.org/attachments/20191119/8211d0f6/attachment-0001.html>
More information about the semantics-public
mailing list