Profile: Exactly one type per representation of a resource

[azaroth42]

Intent: Allow code to instantiate object-oriented classes from a set of triples that describe a resource

Profile implication: Ontologies can be mapped into a class/subclass hierarchy in the manner of an ORM. This handles domain/range of properties and the related SHACL/SHEX validation of those properties. However, as instances in most OO languages can only be of a single class, it requires that the set of triples used to construct this instance should contain exactly one instance of rdf:type where the subject is the resource and the object is the class to instantiate.

From: #15

[dbooth-boston]

I kind of like this idea for newbie use, even though it obviously rubs against a key strength of RDF: that an object can belong to more than one class at a time, both through subclassing and independent roles. But in my experience even in more sophisticated uses of RDF, when an object belongs to multiple classes, there is usually one class that is the preferred class of that object, for purposes of rendering and such, at least within a particular context of use. I wonder whether something like rdf:prefType (analogous to skos:prefLabel) might be helpful for those cases. Just a thought.

[VladimirAlexiev]

In the context of CIDOC CRM (hello @azaroth42 :-)) the prefType is usually the lowest-level most-specific class, and the others come from subclass inference. Higher-level abstract classes are rarely useful.
I guess it's similar in other domains.

Schema strongly shuns abstract classes, even to the extent of refusing to add a super-class of Person and Org (Agent).

[chiarcos]

@azaroth42: Isn't that basically the case already? Multiple rdf:types are factually equivalent to one anonymous class that represents their conjunction (in OWL). (Implementation-wise, it is easier to process conjunctions as multiple rdf:type statements, though.) Or do you want to suggest to abandon anonymous classes?

[chiarcos]

@VladimirAlexiev: For the terminological harmonization of domain terminologies (in my case, annotation schemes for NLP), I've long been arguing that multiple inheritance is a key advantage of OWL modeling in comparison to hierarchical tree structures. Please don't take that away ;) The objective is that, say, something like burning in burning man in is both a verb (lexically) and an adjective (syntactically), that verb and adjective are two different concepts, and that existing domain models (annotation schemes) tend to disagree on the classification if they are forced to chose one or the other. This has the funny consequence that in a traditional, hierarchical model, the "universal" definition of VERB is "depending on language and context" (http://universaldependencies.org/u/pos/VERB.html), i.e., non-universal. In OWL, it can be both.

[namedgraph]

However, as instances in most OO languages can only be of a single class, it requires that the set of triples used to construct this instance should contain exactly one instance of rdf:type where the subject is the resource and the object is the class to instantiate.

"Traditional" ORM for RDF is a pretty bad idea.

There are solutions to this that support multiple types. A prime example is polymorphism support in Jena.

[dbooth-boston]

[FYI, I changed the title of this issue because 'representation' has a special meaning in HTTP and Web architecture.]

[dbooth-boston]

multiple inheritance is a key advantage of OWL modeling in comparison to hierarchical tree structures. Please don't take that away

Maybe multiple inheritance doesn't need to be taken away in order to accomplish this goal. Maybe an object could have a single preferred or default class (rdf:prefType?), while still belonging to other classes, i.e., still allowing multiple inheritance. That might provide users with an easier entry point without taking away multiple inheritance.

[azaroth42]

Representation was intentional. A resource cannot be prevented from having more than one class, but each representation can only expose one at a time.

[azaroth42]

@chiarcos I don't think anonymous classes are a good idea at all, and would propose in a profile of RDF that is intended to be simpler to implement and understand, they should not be used. This should be a separate issue though.

@namedgraph I think you're missing the point of this exercise, which is to discuss a simpler to explain and implement profile of RDF. Thus relying on traditionally understood tools is exactly the approach needed, rather than forcing everyone to be an expert in open world graphs. Unless you plan to implement full polymorphism libraries for every language?

[dbooth-boston]

@azaroth42 , can you explain what you mean by 'representation'? Do you mean it in the WebArch sense? Or the HTTP sense? Or some other sense?

[VladimirAlexiev]

@chiarcos I also think multiple inheritance is often useful.
(And OLIA is imho one of the few good applications of OWL where OWL is necessary).

I just said that high-level abstract classes are not often useful, because nobody queries for them. People sometimes fall into the trap of constructing complex class hierarchies to accommodate the monomorphic nature of rdfs:domain/range.

[namedgraph]

@azaroth42 what's the point of even using RDF if you're clipping its features and expressiveness by using software architectures that predate it by several decades?

To exploit RDF, software has to be built for it, not the way around.