Do not use anonymous classes

[azaroth42]

From #50 ...

Anonymous classes (e.g. a blank node as the object of rdf:type) are complicated to consume and mix ontological layers. The instance shouldn't manage its own class, in an easier to use and understand profile of RDF.

Update: This should only be considered as applying to instance data, not ontology definition. Or only to ABox data, not TBox. Thus owl:Restriction classes can still be bnodes, as they're at the ABox layer.

[VladimirAlexiev]

Quite agree but owl:Restrictions are usually used with blank nodes.
Does it follow these are not nice/useful, or can you propose some better way of using them?

[dbooth-boston]

IMO owl:Restrictions -- at least for newcomer / middle 33% use -- are too confusing to be read in Turtle. If they are expressed in a higher-level form, such as Manchester Syntax, they are much more palatable and understandable. But in the higher-level form, the anonymous class is not visible at all. In other words, owl:Restrictions could still be used without having any visible anonymous classes.

Also, I am not even convinced that owl:Restrictions -- even using Manchester syntax -- are appropriate for newcomer / middle-33% use anyway. I think closed-world domain, range and property declaration are much more appropriate for this target audience, and we have not yet devised good standard ways to declare those, though ShEx and SHACL are a step in that direction.

[azaroth42]

I'm fine with anonymous classes like owl:Restriction as a bnode. Will update the issue to clarify that this only refers to instance data, or ABox if you prefer that terminology.

[dbooth-boston]

@azaroth42 , can you clarify with an example perhaps? I would normally consider classes to be in the Tbox, so I'm not sure what usage you are envisioning.

[rivettp]

Even with true ABox instance data, blank nodes can be very practically useful for representing structured values (where the value has its own properties) where you don't want the hassle, and potential for accidental collisions, from coining a URI for each value. For example a geographic point (having properties for latitude and longitude).
And it's also a strong signal that you don't intend to maintain this value as a distinct resource that can be sensibly referenced by others.
From a syntactic angle, having the structure nested in place can also be a convenience.

[azaroth42]

I think it should be part of the EasierRDF profile that the following pattern is not allowed:

{
  "@id": "https://example.org/some/instance",
  "@type": {"rdfs:subClassOf": "schema:Engineer", "rdfs:subClassOf": "schema:SoftwareDeveloper"},
  "rdfs:label": "Some Person"
}

e.g. a class defined in the instance data which is a blank node, that then has ontology level predicates to define itself.

[chiarcos]

From #50 ...

Anonymous classes (e.g. a blank node as the object of rdf:type) are complicated to consume and mix ontological layers. The instance shouldn't manage its own class, in an easier to use and understand profile of RDF.

Update: This should only be considered as applying to instance data, not ontology definition. Or only to ABox data, not TBox. Thus owl:Restriction classes can still be bnodes, as they're at the ABox layer.

I presume that means
"Thus owl:Restriction classes can still be bnodes, as they're at the TBox layer."

We need anonymous classes also for logical operators (union and intersection). And we need to continue the Turtle representation because it defines how to access that froOWL classes in SPARQL. But restricting it as a recommendation of practice may be a reasonable thing to do.