Property-names and hierarchies - was: Why observedProperty vs observes ? why actedOnProperty vs actsOn ?

[maximelefrancois86]

It is common in SSN to have multiple classes included in the domain/range of properties.

With this mechanism available, why wouldn't we want to make our lives easier, and:

• keep only one of observedProperty vs observes (observes is better IMHO)
• keep only one of actedOnProperty vs actsOn (actsOn is better IMHO)

That way, users won't need to remember which one appy in which situation

[maximelefrancois86]

also:

• keep only one of wasObservedBy vs isObservedBy (isObservedBy is better IMHO)
• keep only one of wasActedOnBy vs isActedOnBy (isActedOnBy is better IMHO)

That way, users won't need to remember that the 'was' version applies to Observation/Actuation, and the 'is' version applies to Sensor/Actuator (which you'll admit is far from obvious from the name of these properties)

[dr-shorthair]

I believe these differences are a result of not wanting to break backward compatibility with legacy implementations.
We have tidied up a few in the less-used parts of the ontology by deprecating in the RDF and omitting mention in the spec.
Not sure how far we should go in the more central parts of the ontology without risking alienating significant parts of the user base.

@kjano may have an opinion here.

[maximelefrancois86]

(I just give the occasional nudge on this topic to sense either reluctance or acceptance.)

[dr-shorthair]

Related issue came up last week as part of Jano's commentary on the OMS and DOLCE alignments. It led to the suggestion to add the Asset class #416 which creates opportunities for deprecating even more old properties in favour of more consistent super-properties. I see the following object-properties with potentially redundant sub-properties:

• forProperty in place of actsOn, isProcedureFor, observes
• propertyFor in place of hasProcedure,
• madeExecution in place of madeActuation, madeObservation, madeSampling
• madeBySystem in place of madeByAcuator, madeBySensor, madeBySampler
• hasDeployment in place of systemDeployment and inDeployment
• deployedAsset in place of deployedSystem and deployedOnPlatform

Do we want to go here?

The approach we've used elsewhere to support backward compatibility is to (i) remove the documentation of the terms from the HTML (ii) in the RDF, mark the undesired properties owl:deprecated true and move them into the sosa-deprecated.ttl and ssn-deprecated.ttl files. The deprecated terms are still included in sosa.ttl and ssn.ttl through owl:includes so no-one's data will be invalid, but the spec is cleaner.

Did I get this correct @kjano @maximelefrancois86 ?

[dr-shorthair]

OTOH - the suggestions from @maximelefrancois86 above require modifying the (soft) axiomatization of some properties, as well as deprecation.

Combining @maximelefrancois86 original issues with the list above we could also have

• forProperty in place of actedOnProperty, observes, observedProperty
• propertyFor in place of wasObservedBy, isObservedBy, wasActedOnBy, isActedOnBy

[ldesousa]

Combining @maximelefrancois86 original issues with the list above we could also have

• forProperty in place of actedOnProperty, observes, observedProperty
• propertyFor in place of wasObservedBy, isObservedBy, wasActedOnBy, isActedOnBy

I don't see an issue with forProperty, since the Property class is not specialised. However, in the opposite sence there is a relevant change in semantics. A property that is not meant to be acted upon, can be mistakenly associated with an Actuation. If this semantic enforcement is deemed outside the objectives of the ontology, then I am fine with it.

[dr-shorthair]

@KathiSchleidt also commented:

Looking for an association between Property and Procedure, I came across a naming alignment issue.
We have the pair:

• sosa:forProperty: Domain Includes sosa:Procedure, sosa:System; Range Includes sosa:Property
• sosa:propertyFor: Domain Includes sosa:Property; Range Includes sosa:Procedure, sosa:System

Then we have the subproperty pair:

• sosa:isProcedureFor; Domain Includes sosa:Procedure; Range Includes sosa:Property
• sosa:hasProcedure: Domain Includes sosa:Property; Range Includes sosa:Procedure

Here visualized:

I thought we'd agreed on verbs and naming a while back.

In addition a question, what I'd really like to use would be the pair forProperty and hasProcedure, how invalid is this mixing of levels?

[dr-shorthair]

I don't think we should change any names carried over from the 2017 edition. These would change the IRIs and thus compromise existing applications.

@maximelefrancois86 has noted that the streamlining I proposed is not compatible with the naming approach used in SAREF etc.

So I'm not sure this issue has any future ...

[dr-shorthair]

Given that there is a disagreement on which direction any streamlining of the property hierarchy, and naming, would take, I propose closing this issue, else tagging it future edition