[x3d-public] X3D Ontology question: can we define default values for attributes and field types; also field renames

[Jakub Flotyński]

Here is an example of a proposed solution for queries, which select 
explicitly specified values or default values - if no value has been 
explicitly specified. The example is for the version property, but it 
would be similar for any other property with a default value. The 
'filter not exists' SPARQL clause checks whether no value has been 
explicitly specified. In such a case, the default value is selected:

:versionDefault a owl:DatatypeProperty ;
    rdfs:subPropertyOf :x3dVersionChoices , :defaultProperty; # :SFString
    rdfs:domain :X3D ; # parent node class
    rdfs:range [ owl:oneOf ( '4.0' ) ] .

:version a owl:DatatypeProperty ;
    rdfs:subPropertyOf :accessTypeInputOutput ;
    rdfs:domain :X3D ;
    rdfs:range :x3dVersionChoices ;
    :versionDefault "4.0" .

select ?node ?ver
     where {
         { ?node :version ?ver }
        union
         {
             { :version :versionDefault ?ver }
             filter not exists { ?node :version ?ver2 }
         }
      }


W dniu 16.12.2020 o 19:45, Don Brutzman pisze:
> X3D Semantic Web Working Group
>
> Attendees: Jakub Flotyński and Don Brutzman.
>
> Thanks for interesting discussion on video conference today. Thoughts 
> we explored:
>
> 1. Most times a field will not have a value defined if the value is 
> default.
>
> Example query: is a given Shape visible?
>
> Default value is true 
> https://www.web3d.org/x3d/tooltips/X3dTooltips.html#Shape.visible
>
> Typically a scene will not define default values but rely on them.
>
> So in HelloWorld.ttl example, for a given :Shape_2_3_2_1 we want to 
> know the value of /visible/ field, otherwise look up value of a (to be 
> defined) /visibleDefault/ field.
>
> This type of construct might well be a common element in many queries, 
> so we might consider whether a repeatable property pattern is possible.
>
> Caution please: nearly every field has a default value, but 
> occasionally two different nodes might each have a commonly named 
> field with different default values.
>
> ---
>
> 2. Autogeneration of the X3D Ontology itself means that we can also 
> autogenerate supporting properties of general interest.
>
> Perhaps we might even combine our automatic definition of concepts.  
> So in addition to defining the versionDefault we might also define 
> versionValue (which equals :version or else :versionDefault if no 
> :version is available).
>
> We want to be terse - but not too terse!  Capturing the meaning is 
> key.  If commodity hardware can process trillions of triples per 
> second, performance is not an impediment.
>
> You make an interesting point that we might generate SPARQL to express 
> the same thing as well.  I agree that is a good pattern to 
> demonstrate... but still expect that we will prefer RDF/OWL for 
> scalability and deployability.
>
> Presumably this will require some creative use of RDF/Owl or perhaps 
> Semantic Web Rules Language (SWRL).  Or, if that is too difficult and 
> not expressible in RDF/OWL, we leave things like :visible and 
> :visibleDefault in ontology and provide design patterns for 
> higher-level usage in SPARQL or SWRL.
>
> What you showed using regular negation looks promising.
>
> If we find ourselves doing a lot of this, we might even create a large 
> SPARQL file with constructs that can be selectively copied (or even 
> imported?) in other SPARQL queries.
>
> ---
>
> 3. Here is another challenge: we recently added a few renames of 
> fields in X3D4 for regularity.
>
> So we will need a way to define "synonym" field names in the ontology 
> to facilitate queries.
>
> Once again getting the pattern is important - we can then autogenerate 
> the synonym relationships from X3DUOM when creating the X3D Ontology.
>
> List of fields found at
>
> * X3D Scene Authoring Hints: Field name changes planned for improved 
> consistency
> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#fieldNameChanges
>
> We need to be able to handle both forms equivalently since an X3D4 
> scene might load an X3D scene.
>
> Agreed that owl:equivalentProperty looks appropriate for this task.
>
> ---
>
> 4. Thanks for excellent discussion today, we are proceeding towards a 
> "next level" of capability, step by step.
>
> Please do check your draft properties/queries and post when 
> ready/tested.  Your progress is super fast.
>
> Having X3D4 voted upon, stable, and immediately matched by our X3D 
> Ontology and example SPARQL query tests is pretty wonderful!
>
> Wednesday 6 January 2021 (0900 pacific, 1700 UTC) is a good "new 
> year's resolution" to resume!
>
> Thanks for a great year.  Please "stay safe" (many queries can answer 
> what that means) and I look forward to 2021 together.
>
> Happy Holidays!  Happy New Year!  8)
>
>
>
> On 12/6/2020 10:42 PM, Don Brutzman wrote:
>> Jakub, during tonight's update I just noticed that we don't include 
>> default values for attributes.
>>
>> * https://www.web3d.org/x3d/content/semantics/semantics.html
>> * http://www.web3d.org/specifications/X3dOntology4.0.ttl
>>
>> Wondering if defining default values in the ontolorgy is worthwhile.  
>> Having those would allow querying of
>> - whether default value matches an instance value for a node's field,
>> - provide default value when no instance value is provided for a 
>> node's field.
>>
>> Not clear if we need default values, but since the question is 
>> expressible then having default values available might be useful in a 
>> query.
>>
>> How would we express defaults?  Given existing X3D Ontology 
>> definitions like:
>> =====================
>> :X3D a owl:Class ;
>>    rdfs:label "X3D is the root node for an Extensible 3D (X3D) 
>> Graphics model." .
>>
>> :version a owl:DatatypeProperty ;
>>    rdfs:subPropertyOf :accessTypeInputOutput ;
>>    rdfs:domain :X3D ;
>>    rdfs:range :x3dVersionChoices .
>> =====================
>>
>> perhaps insert defaultValue as subPropertyOf :version, which could 
>> work for a majority of fields.  however there are some fields with 
>> the same name but different default values for different parent nodes 
>> - for example, there are about a dozen definitions of a "type" field 
>> for various nodes across the full X3D vocabulary and no two are the 
>> same.
>>
>> if somehow that defaultValue information is included in ontology, we 
>> might write Object Properties for hasDefaultValue but that seems 
>> pretty convoluted.
>>
>> Alternatively we could go "brute force" and directly define new 
>> properties on the node's class, something like the following. The 
>> following construct is likely not well expressed but hopefully 
>> describes the idea:
>>
>> :versionDefault a owl:DatatypeProperty ;
>>    rdfs:subPropertyOf :x3dVersionChoices; # :SFString
>>    rdfs:domain :X3D ; # parent node class
>>    rdfs:range '4.0' . # fixed value
>>
>> Whatever the appropriate structure might be (if there is one!) to 
>> define default values, then the pattern will be easy to follow for 
>> automated production in the ontology.
>>
>> Going beyond attributes, we might also create similar expressions of 
>> the X3D field types, for example default value of :SFInt32 is 0.
>>
>> all the best, Don
>
> all the best, Don

Nadawcą korespondencji i jednocześnie administratorem Państwa danych osobowych jest Uniwersytet Ekonomiczny w Poznaniu, al. Niepodległości 10, 61-875 Poznań, z którym można skontaktować się listownie lub poprzez wiadomość e-mail - rodo at ue.poznan.pl
Państwa dane osobowe przetwarzane będą w celu prowadzenia niniejszej korespondencji i przez czas jej trwania. Przysługuje Państwu prawo dostępu do danych, ich sprostowania, ograniczenia przetwarzania, usunięcia, żądania sprzeciwu wobec przetwarzania oraz wniesienia skargi do Prezesa Urzędu Ochrony Danych Osobowych. Szczegółowe informacje na temat ochrony danych osobowych dostępne są w Polityce prywatności: https://ue.poznan.pl/pl/polityka-prywatnosci,c12767/