Avoid creating owl:propertyChainAxiom like properties

[elf-pavlik]

I reference OWL Property Chains since they seem to be a formal way of defining some of properties current draft of interop vocab proposes.

I would like to take for example interop:applicationAuthor and interop:applicationAuthorName. I don't understand need for such flattening. Instead of having

<https://app.example/>
  interop:applicationAuthor <https://alice.example/> ;
  interop:applicationAuthorName "Alice" .

We could simply go with

<https://app.example/>
  interop:applicationAuthor <https://alice.example/> .
<https://alice.example/>
  foaf:name "Alice" .

It seems that vocab tries to define following property chain

interop:applicationAuthorName owl:propertyChainAxiom  ( interop:applicationAuthor foaf:name ) .

I don't see reason for adding such properties to the vocab, especially that we don't intend to rely on OWL reasoning.

[acoburn]

we don't intend to rely on OWL reasoning

I very much agree with @elf-pavlik on this.

[ericprud]

I agree with not relying on OWL reasoning but I don't think that should discourage describing things with OWL. A good fraction of the OWL value proposition is for static analysis, i.e. consistency checks over typing assertions that will never be used for runtime inference. I developed a clinical ontology that used DL with a bit of fancy property chains which provided some guidance for composing SPARQL queries which did the run-time reasoning. I can't say that the investment in OWL ever paid for itself by catching modeling errors, but the clients learned the ontology by navigating around in Protégé, which more than made up for the deficit.

The LDP WG had an opportunity to use an OWL idiom to define indirect membership (iirc). They declined and invented an equally idiomatic way to say the same thing. That was a case where an OWL allergy didn't make things better, just harder to understand or use by OWL-heads. (OTOH, one-namespace apps are easier on readers so maybe it was worth it.)

OWL's fussier than any type system you'd use in software (short of a theorum prover like Coq) and you have to dream up devious tests to make sure you're saying what you think you're saying (case in point, I don't believe that OWL DL property chains work with Datatype Properties, e.g. author name). Producing a sound ontology is kind of a slog and probably won't be as useful as you'd hope.

If someone is inspired to use OWL, I'm in favor, unless it's forcing design decisions which make the actual runtime model more arcane.

[elf-pavlik]

I'd like to shift to my initial question, do we really need to define properties like interop:applicationAuthorName or it is enough to just have interop:applicationAuthor, use someone's WebID as value and we can include statement which uses foaf:name from that WebID document?

[justinwb]

I'd like to shift to my initial question, do we really need to define properties like interop:applicationAuthorName or it is enough to just have interop:applicationAuthor, use someone's WebID as value and we can include statement which uses foaf:name from that WebID document?

That's a fair point. Originally that's what we were doing, but in practical application found ourselves caching the results locally. I'm not against keeping those kinds of optimizations up to implementation to keep the spec lean - worth discussing live in next panel session.

[elf-pavlik]

We still have those items in the vocab. Probably we resolve this issue after moving forward in #210