[semantics-public] X3D Semantic Web minutes 21 OCT 2019: rdf:Listfor listing children nodes? simple object lists instead

John Carlson yottzumm at gmail.com
Sat Oct 26 18:03:50 PDT 2019

I didn’t read all of this, sorry.

I suggest that Hierarchy -> Continuous Hierarchy (see “The Golden Man” by PKD and the Movie “Next”) -> Continuous Collections -> A railroad track -> A ladder -> A dartboard -> Geographic Coordinate System

That’s where my mind has been lately. Grids/Coordinates upon a surface.  Rails to grasp.   Steps to go up and down.

Those are the semantics. That’s what you’re trying to capture in RDF.  The only way I know how to capture continuity is with an equation, or a drawing.  That is, RDF might incorporate Movies/Images and Shapes (possibly via filenames) and not only symbols.

Sent from Mail for Windows 10

From: Brutzman, Donald (Don) (CIV)
Sent: Saturday, October 26, 2019 7:22 PM
To: X3D Semantic Web Working Group
Cc: X3D Graphics public mailing list
Subject: Re: [semantics-public] X3D Semantic Web minutes 21 OCT 2019: rdf:Listfor listing children nodes? simple object lists instead

[Summary: problem solved, analysis follows.]

Following up: we should indeed be careful with the use of rdf:List since it does not include any entailment implications and has a number of limitations.  The gnarliness of the Owl EnumeratedDatatype pattern shows how involved this can get if order is to be preserved explicitly - even then, querying is probably difficult.

Specification excerpt follows (hang on!)

RDF 1.1 Semantics
W3C Recommendation 25 February 2014

D.3 RDF collections

RDF Collection Vocabulary
rdf:List rdf:first rdf:rest rdf:nil

RDF provides a vocabulary for describing collections, i.e.'list structures', in terms of head-tail links. Collections differ from containers in allowing branching structure and in having an explicit terminator, allowing applications to determine the exact set of items in the collection.

As with containers, no special semantic conditions are imposed on this vocabulary other than the type of rdf:nil being rdf:List. It is intended for use typically in a context where a container is described using blank nodes to connect a 'well-formed' sequence of items, each described by two triples of the form

_:c1 rdf:first aaa .
_:c1 rdf:rest _:c2 .

where the final item is indicated by the use of rdf:nil as the value of the property rdf:rest. In a familiar convention, rdf:nil can be thought of as the empty collection. Any such graph amounts to an assertion that the collection exists, and since the members of the collection can be determined by inspection, this is often sufficient to enable applications to determine what is meant. The semantics does not require any collections to exist other than those mentioned explicitly in a graph (and the empty collection). For example, the existence of a collection containing two items does not automatically guarantee that the similar collection with the items permuted also exists:

_:c1 rdf:first ex:aaa .
_:c1 rdf:rest _:c2 .
_:c2 rdf:first ex:bbb .
_:c2 rdf:rest rdf:nil .

does not entail

_:c3 rdf:first ex:bbb .
_:c3 rdf:rest _:c4 .
_:c4 rdf:first ex:aaa .
_:c4 rdf:rest rdf:nil .

Also, RDF imposes no 'well-formedness' conditions on the use of this vocabulary, so that it is possible to write RDF graphs which assert the existence of highly peculiar objects such as lists with forked or non-list tails, or multiple heads:

_:666 rdf:first ex:aaa .
_:666 rdf:first ex:bbb .
_:666 rdf:rest ex:ccc .
_:666 rdf:rest rdf:nil .

It is also possible to write a set of triples which under-specify a collection by failing to specify its rdf:rest property value.

Semantic extensions may place extra syntactic well-formedness restrictions on the use of this vocabulary in order to rule out such graphs. They may exclude interpretations of the collection vocabulary which violate the convention that the subject of a 'linked' collection of two-triple items of the form described above, ending with an item ending with rdf:nil, denotes a totally ordered sequence whose members are the denotations of the rdf:first values of the items, in the order got by tracing the rdf:rest properties from the subject to rdf:nil. This permits sequences which contain other sequences.

The RDFS semantic conditions require that any subject of the rdf:first property, and any subject or object of the rdf:rest property, be of rdf:type rdf:List.

Even stronger warnings are provided by Shelley Powers in book _Practical RDF_ published by O'Reilly, directly recommending that rdf:List collection should only be used when no other construct meets the needs.

That said, a much (much much) simpler solution presents itself.  If we were to explicitly list hasChildren ("children" field, not arbitrary child node) relationships as follows,

:Group_2_2 a owl:NamedIndividual, x3do:Group ;
        x3do:hasParent :Scene ;
        x3do:hasChildren :ViewUpClose ;
        x3do:hasChildren :Transform_2_2_2 ;
        x3do:hasChildren :Transform_2_2_3 .

an equivalent form is to use the comma syntax in Turtle to present this information even more tersely:

:Group_2_2 a owl:NamedIndividual, x3do:Group ;
        x3do:hasParent :Scene ;
        x3do:hasChildren :ViewUpClose ,  :Transform_2_2_2,  :Transform_2_2_3 .

This form is described in many places, including

RDF 1.1 Turtle - Terse RDF Triple Language, 2.3 Object Lists

... and so have done so in the X3dToTurtle.xslt conversion.  Latest version of HelloWorld.ttl matches the form above and passes all prior query tests.

Have added two new queries to test.

# X3dHelloWorldQuery_04.rq
   Query HelloWorld.ttl to show contained geometry, appearance, material and
   texture field SFNode values within each Shape node.

| shapeNode       | geometryField      | appearanceField        | materialField             | textureField          |
| "Shape_2_2_2_1" | "Sphere_2_2_2_1_1" | "Appearance_2_2_2_1_2" | "MaterialLightBlue"       | "ImageCloudlessEarth" |
| "Shape_2_2_3_1" | "TextMessage"      | "Appearance_2_2_3_1_2" | "MaterialLightBlue-USE-1" |                       |

# X3dHelloWorldQuery_05.rq
   Query HelloWorld.ttl to show all nodes in 'children' field contained within any Group node.

| groupNode   | childrenNodes     |
| "Group_2_2" | "Transform_2_2_3" |
| "Group_2_2" | "ViewUpClose"     |
| "Group_2_2" | "Transform_2_2_2" |

Note that for peer nodes within a scene graph, the current mapping doesn't capture ordering of nodes except in the node labeling (which helps most output sorting, at least).

If we want to capture the semantics for children fields where order is important (for example, children of Switch or LOD) then we will either need to use the owl:EnumeratedList contruct (yikes!) or perhaps simply define a new property such as x3do:peerOrder ranging from 0 to n.  In that way, posing a query matching "show me initial/simplest child of each Switch or LOD" would be possible.

Once again interesting to note that no changes were needed in X3D Ontology to make this week's improvement.

Published online.  Now running regression tests with new .ttl encoding for MFNode fields on all X3D Examples, will upload when complete.

Better and better!   8)

On 10/21/2019 10:23 AM, Brutzman, Donald (Don) (CIV) wrote:
> Seems like a simple rdf:List might work?
> 	https://www.w3.org/TR/rdf-schema/#ch_list
> 	5.2.1 rdf:List
> 	rdf:List is an instance of rdfs:Class that can be used to build descriptions of lists and other list-like structures.
> We should be careful here, a little more may be needed... since SFNode and MFNode field types are not defined yet in X3D Ontology, this will be good to sort out.
> https://www.web3d.org/x3d/content/semantics/ontologies/X3dOntology4.0.ttl
> # SFNode TODO questionable, remove or refactor? .
> # MFNode TODO questionable, remove or refactor? .
> On 10/21/2019 10:11 AM, Brutzman, Donald (Don) (CIV) wrote:
>> This should be an rdf relationship of some sort...  hmmm.  Specified multiple times, it would look like:
>> :Group_2_2 a owl:NamedIndividual, x3do:Group ;
>>       x3do:hasParent :Scene ;
>>       x3do:hasChildren :ViewUpClose ;
>>       x3do:hasChildren :Transform_2_2_2 ;
>>       x3do:hasChildren :Transform_2_2_3 .
>> TODO: Jakub will figure out if an even better relationship is possible, instead of the repeated properties above.  An ordered list of some type is preferable because the order of children nodes can be important... For example, both Switch and LOD have order-dependent children for their functionality to work properly.
>> This is an RDF question... as partial answer, it looks like there is an RDF construct to apply. Jakub found:
>> 	OWL Web Ontology Language Reference
>> 	6.2 Enumerated datatype
>> 	https://www.w3.org/TR/owl-ref/#EnumeratedDatatype
>> Whoa, the construct there looks pretty gnarly... hopefully we can find a corresponding .ttl representation that is simpler... whatever works.  Still a TODO item.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/semantics-public_web3d.org/attachments/20191026/e838e4ff/attachment-0001.html>

More information about the semantics-public mailing list