[x3d-public] X3D Ontology question: can we define default values for attributes and field types; also field renames
Don Brutzman
brutzman at nps.edu
Sat Jan 2 19:35:55 PST 2021
Thanks and Happy New Year, Jakub. Hope that you have enjoyed a great holiday season.
1. Can we resume weekly meetings on Monday or Tuesday this quarter? Looks like we have Audio (after Communications team) on Wednesday, CAD DPS on Thursday and X3D on Friday.
2. Correction: X3D version attribute is a bad choice because, actually, while version attribute is required there no default value for version defined on the X3D statement. This policy is somewhat unique and is intended to force an author (or tool) to be explicit about what version is used in a scene.
So let's look at other attributes such as Material transparency default of 0, etc.
3. The rdfs: declarations you suggest seem to work fine in Protege. I didn't try the owl yet, am hoping to refine further.
However these constructs seem accurate but really verbose, and might significantly increase the size of the ontology (already 725KB, albeit with a lot of embedded comments). The file size won't hurt triple performance but am wondering if we can't get terser for improved clarity.
Your second definition for :version is interesting, might it work if we avoided :versionDefault and simply referred to any default value as :default instead. Something like this result occurs for Material node:
:shininess a owl:DatatypeProperty ;
rdfs:subPropertyOf :accessTypeInputOutput ;
rdfs:domain :TwoSidedMaterial ;
rdfs:range :SFFloat ;
:default 0.2 .
:specularColor a owl:DatatypeProperty ;
rdfs:subPropertyOf :accessTypeInputOutput ;
rdfs:domain :TwoSidedMaterial ;
rdfs:range :SFColor ;
:default "0 0 0" .
:transparency a owl:DatatypeProperty ;
rdfs:subPropertyOf :accessTypeInputOutput ;
rdfs:domain :TwoSidedMaterial ;
rdfs:range :SFFloat ;
:default 0 .
I could keep working on correct typing of default values.
Not sure what SPARQL syntax would be, but it would no doubt be consistent throughout...
Protege seems agreeable with autogenerated :default values.
What do you think of this pattern?
On 12/17/2020 1:23 AM, Jakub Flotyński wrote:
>
>
> 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/
>
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 x3d-public
mailing list