On 2/16/2015 21:52, Thomas Baker wrote:
>
> The latter example has the (to me) clear advantage of _not_
> carrying the baggage of RDFS class semantics:
>
> -- In the former example, instances of ex:MyShape could be inferred to
> be instances of ex:ParentShape. This seems both confusing and brittle.
Constraints are inherited from superclasses, i.e. subclasses can only
narrow down superclasses. That aligns with typical RDFS/OWL semantics
and therefore inferencing is no problem. In fact the LDOM engine will
walk up the class hierarchy to collect constraints anyway. I would not
consider this a bug but a feature.
>
> -- I find the notion of shapes having _class_ extensions -- since in RDFS,
> each class is associated with a set of instances as a class extension
> -- quite confusing because it seems to blur the distinction between a
> model of reality and a template to match against some data on hand.
OWL does the same thing already, i.e. many class definitions are not
meant to be instantiated directly but only serve as part of other class
definitions. In OO systems this is comparable to abstract classes, which
is a well-established pattern.
>
> In other words, I do not see what RDFS semantics add to the notion of a
> data template. I do see that on the other hand, the term 'class' is
> already horribly overloaded, for example with RDFS classes and OOP
> classes as entirely different things. To my way of thinking, saying
> that a shape is a class only compounds that confusion.
Likewise, pretending that "Shapes" are something different than classes
unnecessarily alienates a potentially very large user base. Finally, you
end up with a parallel semantic web, throwing away all the useful work
that people have already spent on building class trees and their
property definitions.
I believe it all boils down to personal taste and speculation here.
Maybe the outcome will be that we need to support both and let "the
market" decide.
Thanks,
Holger
|