[semantics-public] X3D Semantic Web minutes 21 OCT 2019: rdf:List for listing children nodes? simple object lists instead
Jakub Flotyński
flotynski at kti.ue.poznan.pl
Mon Nov 4 09:10:44 PST 2019
Don,
please take a look at the links:
http://www.snee.com/bobdc.blog/2014/04/rdf-lists-and-sparql.html
https://www.w3.org/TR/turtle/#collections
https://www.w3.org/TR/sparql11-query/#collections
It seems that collections can be encoded in Turtle and SPARQL in a much
more concise form then using rdf:first, rdf:rest and rdf:nil. We can
simply use the () brackets, e.g.,
:material :diffuseCollor (0 1 0) .
Thus, collections are probably the fine solution to our problem because
they can be queried and used for reasoning in terms of their individual
elements. This is not the case if we use strings for representing
vectors of values. In addition, they are limited to the explicitly
listed values, as opposed to containers (bags, sequences and alternatives).
Best regards
Jakub
W dniu 27.10.2019 o 02:21, Brutzman, Donald (Don) (CIV) pisze:
> [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
> https://www.w3.org/TR/rdf11-mt
>
> D.3 RDF collections
> https://www.w3.org/TR/rdf11-mt/#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
> https://www.w3.org/TR/turtle/#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
More information about the semantics-public
mailing list