[x3d-public] potential solution to accessType and accessTypeChoices in X3dOntology
Don Brutzman
brutzman at nps.edu
Mon May 25 17:50:03 PDT 2020
[cc: x3d-public list]
Summary: design and debugging in RDF/OWL for subject-line topic.
On 5/25/2020 9:33 AM, Jakub Flotyński wrote:
> Now, I see that enumerations on datatypes work as well but must be specified directly in the range of a datatype property.
>
> The following works in Protege and it is probably the better solution than using the object accessType property:
>
> :accessType rdf:type owl:DatatypeProperty ;
> rdfs:range [ rdf:type rdfs:Datatype ;
> owl:oneOf [ rdf:type rdf:List ;
> rdf:first "initializeOnly"^^xsd:string ;
> rdf:rest [ rdf:type rdf:List ;
> rdf:first "inputOnly"^^xsd:string ;
> rdf:rest [ rdf:type rdf:List ;
> rdf:first "inputOutput"^^xsd:string ;
> rdf:rest [ rdf:type rdf:List ;
> rdf:first "outputOnly"^^xsd:string ;
> rdf:rest rdf:nil
> ]
> ]
> ]
> ]
> ] .
>
> So we can replace the former accessType definition with the aforementioned one and remove accessTypeChoices.
>
> Best regards
> Jakub
>
> W dniu 25.05.2020 o 18:23, Jakub Flotyński pisze:
>> Don,
>>
>> this could be a solution to our problem (below). It is accepted by Protege and conforms to OWL. However, it requires that accessType be an OWL object property, which indicates objects rather than literal values. The solution with accessTypeChoises being a subclass of rdfs:Datatype is invalid in Protege, however, it is probably still compliant with OWL.
>>
>> Best regards
>> Jakub
>>
>> :accessType rdf:type owl:ObjectProperty ;
>> rdfs:range :AccessTypeChoices .
>>
>> :AccessTypeChoices rdf:type owl:Class ;
>> owl:equivalentClass [ rdf:type owl:Class ;
>> owl:oneOf ( :initializeOnly
>> :inputOnly
>> :inputOutput
>> :outputOnly
>> )
>> ] .
>>
>> :initializeOnly rdf:type owl:NamedIndividual .
>> :inputOnly rdf:type owl:NamedIndividual .
>> :inputOutput rdf:type owl:NamedIndividual .
>> :outputOnly rdf:type owl:NamedIndividual .
Sorry to miss the call today Jakub, it is a holiday here in USA and I got distracted by another problem... you are welcome to text or call my cell if ever needed.
Agreed that there is no necessity to link the existing accessTypeChoices, duplication of information is OK.
Can still meet if not too late for you.
Some candidate approaches:
1. Wondering, why not a similar pattern to what you are stating below but without all of the list convolutions, perhaps
:accessType rdf:type owl:DatatypeProperty ;
rdfs:range [ rdf:type rdfs:Datatype ;
owl:oneOf ( 'initializeOnly' "inputOnly' 'outputOnly' 'inputOutput' ) ] .
However, we are not trying to modify classes (X3D nodes) per se, but rather are trying to note an aspect of each contained field. Some fields are simple types (owl:DatatypeProperty) and some fields are node types, so a pair of mechanisms may be needed eventually... but for now we just need simple types.
- - -
2. Wondering harder, we need to focus on end result which is attached to each and every field name, which themselves are owl:DatatypeProperty.
So something like the following excerpt needs to be extended further, as shown by '# accessType=inputOutput' comments:
# - - - - - - - - - - - -
:WorldInfo a owl:Class ;
rdfs:subClassOf :X3DInfoNode ;
rdfs:label "WorldInfo contains a title and simple persistent metadata information about an X3D scene. This node is strictly for documentation purposes and has no effect on the visual appearance or behaviour of the world." .
:info a owl:DatatypeProperty ;
rdfs:domain :WorldInfo ;
# accessType=inputOutput
rdfs:range :MFString .
:title a owl:DatatypeProperty ;
rdfs:domain :WorldInfo ;
# accessType=inputOutput
rdfs:range :SFString .
# - - - - - - - - - - - -
Next looked at Protege interface to see what options we have.
Note that each simple field is a owl:DatatypeProperty, and that we already define rdfs:domain and rdfs:range.
So what other aspects of a owl:DatatypeProperty are available? Looks like SubProperty and Annotations.
Conceivably we could create subproperties of the four accessType definitions.
:accessTypeInputOutput a owl:DatatypeProperty ;
rdfs:domain xs:NMTOKEN ;
rdfs:range "inputOutput" .
:accessTypeInitializeOnly a owl:DatatypeProperty ;
rdfs:domain xs:NMTOKEN ;
rdfs:range "initializeOnly" .
:accessTypeInputOnly a owl:DatatypeProperty ;
rdfs:domain xs:NMTOKEN ;
rdfs:range "inputOnly" .
:accessTypeOutputOnly a owl:DatatypeProperty ;
rdfs:domain xs:NMTOKEN ;
rdfs:range "outputOnly" .
Progress, these constructs passed Protege. Interestingly when looking at interface, it listed the range strings (e.g. "outputOnly" etc.) Annotations.
I then went on trying to revise properties list for WorldInfo fields. Changing just one field worked:
:title a owl:DatatypeProperty ;
rdfs:subPropertyOf :accessTypeInputOutput ;
rdfs:domain :WorldInfo ;
rdfs:range :SFString .
Then tried to change the :info field, but it failed.
:info a owl:DatatypeProperty ;
rdfs:subPropertyOf accessTypeInputOutput ;
rdfs:domain :WorldInfo ;
rdfs:range :MFString .
Noting that :HAnimHumanoid also has an :info, and changing that as well, also failed in Protege. Not sure why.
:info a owl:DatatypeProperty ;
rdfs:subPropertyOf accessTypeInputOutput ;
rdfs:domain :HAnimHumanoid ;
rdfs:range :MFString .
So... I created the same relationships using Protege itself (from unmodified ontology) and saved the result as turtle, which is a helpful comparison technique. Looked in output and found:
... first, :title matches exactly.
### http://www.web3d.org/specifications/X3dOntology4.0#title
:title rdf:type owl:DatatypeProperty ;
rdfs:subPropertyOf :accessTypeInputOutput ;
rdfs:domain :WorldInfo ;
rdfs:range :SFString .
... second, :info field triples were unified/restructured somewhat by Protege using turtle shortcuts.
### http://www.web3d.org/specifications/X3dOntology4.0#info
:info rdf:type owl:DatatypeProperty ;
rdfs:subPropertyOf :accessTypeInputOutput ;
rdfs:domain :HAnimHumanoid ,
:WorldInfo ;
rdfs:range :MFString .
So the Protege form appears to have the exact same information as manual changes... do you agree? Puzzling why prior form failed, another Protege idiosyncracy perhaps.
The first pattern is much preferred since all field information is collected together for each node, much more readable for students (and other humans).
If this approach looks good to you, I will attempt to get one pattern or the other to work in our autogenerated X3D Ontology. Am happy to discuss (and share screens) later this week if you like.
Of note in the Protege interface is that all of the subproperties get listed together under their parent property. So yet another difficulty is possible, not sure if definitions for all fields sharing same name always have the same accessType... will investigate that further too.
Hope you are well and safe. Thanks for considering this latest piece of the puzzle, hopefully we can fit it into place.
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