Properties in RDF are prefixed by class names

[kenwenzel]

The ontology prefixes all property IRIs with names of the declaring classes as in: https://github.com/admin-shell-io/aas-specs/blob/6ee8a5148153831ac81ff0d8408aad03219a207e/schemas/rdf/rdf-ontology.ttl#L265

Usually ontologies define a global property hierarchy that can be reused for different classes. Maybe it is also possible that the AAS ontology follows this practice.

I am aware that this might lead to name clashes between properties and that rdfs:domain/rdfs:range need to be replaced by owl:Restricions on the respective classes.

[mristin]

Reposted from #163, let's continue the discussion here.

@kenwenzel wrote:

Do you think it is also possible to move all properties into the AAS namespace as mentioned in issue https://github.com/admin-shell-io/aas-specs/issues/43 for V3RC02? This would really simplify the usage of the RDF syntax. If property ranges are an issue then OWL local property restrictions can be used to express them. The attributes in the XML serialization are also not in different namespaces.

@changqin26 could you please help? I have basically no clue about RDF.

[kenwenzel]

Usually an ontology (or RDF vocabulary) defines separate hierarchies for classes and properties. A simple example is the FOAF vocabulary that, for example, defines the property foaf:name.

If rdfs:domain and/or rdfs:range are defined for a property then this implies that the subject (rdfs:domain) or the value (rdfs:range) are of the given type. This is exactly the opposite as one would expect when modeling with UML or other object-oriented languages. For example, if we have the definition :barkSound rdfs:domain :Dog and a triple :cat :barkSound "meow" then this would lead to the inference that :cat a :Dog.

To prevent this inference from happening only very general concepts should be chosen for rdfs:range and rdfs:domain. For example, FOAF has chosen owl:Thing as rdfs:domain of foaf:name. So it is allowed to use foaf:name almost for everything without the implication that wrong inferences about the subject type are drawn.

Now we can ask the question how property domains and ranges can be further restricted without the implications of rdfs:range and rdfs:domain. The answer to this question are OWL property restrictions. They allow to specify local constraints for properties on classes. So the class :Dog could be defined as

:Dog a owl:Class ; rdfs:subClassOf [ owl:onProperty :barkSound ; owl:allValuesFrom xsd:string ] .

I think that this is also the correct way to define AAS properties in RDF.

The advantages are that in general the modeling in RDF will be easier as all properties would live in the aas: namespace and that AAS RDF would then be compatible with prefixed names in SPARQL and TURTLE. Those languages don't allow / or # in the local part of a prefixed name and therefore require either full URIs or many prefix definitions.

I can help to transform the current RDF ontology into a version that uses OWL property restrictions. I am also aware that this affects the code generator but I think the future advantages are worth it.

[changqin26]

@kenwenzel, thanks for your comments and I think you made a point. However, in the current published version of Spec Spec 3.0 on the page 126, it defines: A concrete unique identifier is defined as follows: <AAS Unique Concept Identifier> ::= (<Namespace> | <Namespace Qualifier>)”/”<AAS Concept Identifier> <AAS Concept Identifier> ::= <AAS Class Name>[(<AAS Attribute>|<AAS Enumeration>)] <AAS Attribute> ::= “/”<AAS Attribute Name>[{“/”<AAS Attribute Name>}*] <AAS Enumeration> ::= [{“/”<AAS Attribute Name>}*]”/”<AAS Enumeration Value>

In this case, properties in RDF should for now be prefixed by class names. For further changes for V3RC02, I'd suggest a broader discussion with @BirgitBoss and @sebbader .

[kenwenzel]

Thank you @changqin26. I wasn't even aware of this rule.

But I would repeat that this is really unusual for an RDF vocabulary and even the AAS XML Schema doesn't follow this rule. All AAS XML attributes are definied in the namespace http://www.admin-shell.io/aas/3/0 as can be seen here: https://github.com/admin-shell-io/aas-specs/blob/76275c0248bb999e38a3517b84590b3ea87ee4a4/schemas/xml/AAS.xsd#L2

I would like to discuss this further if this is possible.

[sebbader]

Hi @kenwenzel, you are of course right with the point that the pattern for the properties is definitely not following the RDF conventions. Actually, the earlier versions of the ontology had one single namespace. However, and that's what Chang posted, the identifier grammar was accepted as a normative part of the standard earlier already, and therefore must be used.

[sebbader]

So, our options are a bit limited here. I agree that the XML namespaces look differently. But, that's rather an inconsistencies of the XML serialization in relation to the Part 1 specifications.

[kenwenzel]

@sebbader Who is responsible for the identifier grammar and how would, for example, a compact binary encoding of the AAS should like if this grammar must be followed? If you also think that it is better to use a single namespace then we should do our best to change the current situation.

Is it expected that two different properties with the same short name (like value) are used on one AAS object? If it is not the case then the globally unique identifier could be reconstructed by simply concatenating the most specific RDF type of the object with the local name of the property.

[sebbader]

Is it expected that two different properties with the same short name (like value) are used on one AAS object?

Yes, that's actually possible, and did happen. I am not sure anymore if after the latest changes there are still such name clashes but that can happen.

[sebbader]

The main issue is the question about priorities. Current focus is on the submodel templates and how to fill the AAS with concrete data. That implies in particular that already settled topics will not be opened (right now). And, my personal opinion, also shouldn't, just so that we invest all our time and power in the other topics.

[kenwenzel]

Yes, I understand that. I just think that changes at a later point in time will be even harder if more and more AAS data becomes available. Also RDF tooling could be better leveraged if the RDF vocabulary would be more "standard conformant".

[sebbader]

The correct process is to put the finding into the AAS Part 1 review form and thereby propose it to the working group. Or, even better, join the WG and collaboratively make the solution happening :-) @kenwenzel, don't get me wrong, I agree with you that your suggestion is following to the RDF conventions and thereby preferable. Still, the design decision has been made already, so opening it now will have side-effects and effect - currently critical - adoption processes.

[sebbader]

Also RDF tooling could be better leveraged if the RDF vocabulary would be more "standard conformant".

Absolutely true. Nevertheless, many things have been decided already, and opening them again will make us circling a lot. At this point I don't see that we have the time, that's all.

[sebbader]

And yes, a later change will even cause more trouble. Still, we don't have a functional bug right now, so the priority is not at number 1

[mristin]

Closing the issue due to inactivity. Please re-open if there are any new actionable insights.

[VladimirAlexiev]

The Electrical CIM is a comprehensive set of standards in the electrical domain. It is derived from a UML model and is guilty of the same overly long prop names, see https://github.com/3lbits/ElBits_Utillity_Standardization/issues/331 .

But CIM uses . as delimiter, whereas AAS made the blunder of using /. So if you want to use prefixed names (CURIEs) in turtle/sparql, you're forced to use a backslash: aas:AssetAdministrationShell\/assetInformation This is very ugly and I've seen it in some sample sparql.

A better option is to define a lot more prefixes, which I have used eg in #383, eg:

    aas_property:category aas_category:CONSTANT;
    aas_hasKind:kind aas_modelingKind:INSTANCE;
    aas_hasSemantics:semanticId [
      a aas:Reference;
      aas_reference:key [
        a aas:Key;
        aas_key:index "0"^^xsd:integer;
        aas_key:type aas_keyElements:GLOBAL_REFERENCE;

That looks better, and has the pleasing characteristic that property CURIE and value CURIE have a word in common, giving some assurance that they pair correctly: aas_property:category aas_category:... After many years looking at semantic data, I'm not ashamed to say this creates a song-like soothing cadence ;-).

---

this might lead to name clashes between properties

• The props aas_hasKind:kind and aas_hasSemantics:semanticId have a redundancy in their name: something that has kind is indeed HasKind (DUH!), so there's no need to repeat it.
• It should be easy to check whether the last part (pure prop name) across all of AAS has conflicts. We've done this for CIM, which is much bigger
• In the rare cases of conflict, the prop could be renamed eg type -> keyType

@kenwenzel There may be a bigger issue lurking behind the naming issue that you've raised:

• Are there AAS props that are over-specified to apply to only 1 class, and have siblings that mean the same but are nested under different classes?
• Such over-specified props are an anti-pattern: props should vary by their range and meaning, not by their domain (attachment)
• Eg the FIBO ontology, which is MUCH bigger than AAS (300 modules, 400 namespaces), reuses props as much as it can across classes. (And yes, it uses owl:Restriction for attachment)

[kenwenzel]

As the AAS JSON format does not use prefixed properties I am not sure why the RDF format requires this: https://github.com/admin-shell-io/aas-specs/blob/master/schemas/json/examples/generated/Submodel/maximal.json

[kenwenzel]

@mristin Could you re-open this issue, please?

Based on the naming conventions of the JSON format it should be easy to decide on the removal of the prefixes in the RDF vocabulary.

[mristin]

Re-opening since active again.

[VladimirAlexiev]

@kenwenzel in https://github.com/admin-shell-io/aas-knowledge-graph/issues/1 proposes to remove class names from prop names.

• @sebbader @sebbader-sap @mristin @changqin26 what do you think?
• I agree.