Re: Fwd: Re: ISSUE-23: sh:ShapeClass?

On 5/14/15 7:09 PM, Dimitris Kontokostas wrote:
>
> If the metaclass is used only for the people who prefer to avoid the 
> typing of an extra type statement I would prefer they do it in their 
> own namespace. I would rather make sh:ShapeClass a subClass of 
> sh:Shape only but this is only my opinion,

What would be the purpose of sh:ShapeClass if it were just a subclass of 
sh:Shape?

To me, if we allow mixing the URIs (which I hope) then sooner or later 
somebody will create such a mixed metaclass anyway (e.g. tq:ShapeClass, 
possibly with special support in TopBraid tools). We should rather 
acknowledge that this will happen and reserve a proper URI for that 
construct.

There have been other cases where language designers (with good 
intentions) have tried to protect users from certain situations, to 
reduce worst-case complexity. But it is very hard for such a small group 
as ours to anticipate all practical use cases and the best practices 
that people will want to use in projects.

Regarding some comments from the call today, yes I agree that not every 
ontology should be enriched with such constraints, especially if the 
ontology is meant to be reusable as linked data. But this choice should 
be left to the creators of these models - there are plenty of controlled 
use cases where mixing classes and shapes will be a good practice. I'd 
argue that many (if not most) successful semantic technology 
applications live inside of company networks anyway. Even on the open 
web there are cases where we want to communicate the relevant properties 
of a class to *everyone* that subscribes to our namespace. Whether we do 
this via an indirect link (sh:scopeClass) or directly at the class is 
merely a syntactic difference, and I'd vote for the more maintainable 
and intuitive syntax.

Thanks,
Holger