Re: shapes and classes: different

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I guess I'm confused as to what you are asking.

If you are asking whether there are use cases that cannot be handled with
just RDF classes, then the answer is that none of the use cases can.
Therefore shapes are of more utility to the working group than classes.

If you are asking whether there is no way of augmenting the notion of
classes while still retaining their class nature that can handle all the use
cases then the answer is no.  You could just create an enhanced version of
OWL constraints including closed world recognition, the ability to access
the names of IRI nodes, functions. and maybe some more stuff.  In this
version of OWL constraints you create new classes that are equivalent to
whatever recognition is provided by the shapes.  The only argument against
this analysis is that the "new" classes are never meant to be instantiated
and thus perhaps are not truely classes.

If you are instead asking for something in the middle, then this middle is
as of yet undetermined.  My view is that the middle is something like:
1/ classes are as in LDOM, i.e., RDFS classes plus constraints, and
2/ shapes are as in ShExC, i.e., you can't assert membership in a shape.
In this particular middle the bug example cannot be handled by classes
because there is no typing and thus nothing to start the class-based
constraints whereas shapes plus OSLC-like controls work fine.  The same
analysis can be made for any use case that does not have explicit rdf:type
triples in the data.

peter


On 02/02/2015 01:22 PM, Jerven Bolleman wrote:
> Hi Peter, All,
> 
> I am jumping back in at this e-mail because I think it contains a great
> idea. On 26 Jan 2015, at 19:14, Peter F. Patel-Schneider
> <pfpschneider@gmail.com> wrote:
> 
> It is certainly the case that OWL classes have the characteristics of
> both shapes and classes because you can both assert that objects belong
> to OWL classes and provide precise conditions for belonging to OWL
> classes. However, it is possible to build a class system (e.g., RDFS)
> where classes are not shapes and a shape system (e.g., ShExC) where
> shapes are not classes.
> 
> Having shapes also be classes or classes also be shapes doesn't follow
> from the bare notions of shapes and classes.  It is instead a decision
> whose consequences need analysis.
> 
>> Instead of discussing this the WG needs some data. As the WG is
>> usecase driven why don’t the shape proponents find a usecase that is
>> not supportable by the class story but where shapes work (e.g within
>> the next two months). Then the class proponents take that usecase and
>> try to show that their class solution can tackle the problem.
> 
>> If then shapes can do something classes can’t (that meets a usecase),
>> then the standard should use shapes. If not the question one becomes
>> one of Usability and Understanding. At which point a careful social
>> experiment needs to be designed, to see what is really more
>> understandable (and for whom).
> 
>> I.e. you should stop discussing for a while because you need more data
>> before it becomes worthwhile to really talk. Currently its to much
>> opinion (mine included).
> 
>> Regards, Jerven
> 
> peter
> 
> 
> 
> 
> On 01/26/2015 08:12 AM, Jerven Tjalling Bolleman wrote:
>>>> I really can't help myself...
>>>> 
>>>> On 26/01/15 15:12, Peter F. Patel-Schneider wrote: The most
>>>> important aspect of classes is that you state that objects belong
>>>> to them.  If you don't state that objects belong to X, X is not a
>>>> class.
>>>> 
>>>> The most important aspect of shapes is that you provide conditions 
>>>> stating precisely when an object belongs to them.   If you don't
>>>> provide conditions stating precisely when an object belongs to X, X
>>>> is not a shape.
>>>> 
>>>> Having shapes also be classes implies that you state that objects
>>>> belong to shapes.  Having classes also be shapes implies that you
>>>> provide recognition conditions for classes. Both situations are
>>>> possible, but both have consequences.
>>>>> Your word shape is my word owl:Class. Allowing class membership 
>>>>> inference from recognition conditions is as normal as class
>>>>> member ship assertion directly in the data. But I am absolutely
>>>>> flabbergasted that I am having this argument with one of the OWL2
>>>>> editors!
>>>> 
>>>>> Basically I am reading your response as class membership only
>>>>> inferred is "shape membership". Class membership asserted is not
>>>>> "shape membership". Or paraphrased: Shapes only allows triples
>>>>> with the shape:member predicate (IMO equivalent to rdf:type) to
>>>>> be inferred and not asserted.
>>>> 
>>>> 
>>>> 
>>>> peter
>>>>> 
>>>> 
>> 
> 
> ------------------------------------------------------------------- 
> Jerven Bolleman                        Jerven.Bolleman@isb-sib.ch SIB
> Swiss Institute of Bioinformatics      Tel: +41 (0)22 379 58 85 CMU, rue
> Michel Servet 1               Fax: +41 (0)22 379 58 58 1211 Geneve 4, 
> Switzerland     www.isb-sib.ch - www.uniprot.org Follow us at
> https://twitter.com/#!/uniprot 
> -------------------------------------------------------------------
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU0AS3AAoJECjN6+QThfjzpxkH/jF9QB4JapTZ1Mr7gnOCHjM9
i3BoHez1v76mv0V+wpIAjXKym0jKrB83S7k9PXMQrDc8ckz+BDvVSc4FHH4PF1m2
B8jUQARHFllTeF3CNKxJua0875UXKuscJkjHsxwTcqqS2F23CB6ADEZqhYorD83O
ja16S42WliVbHDrKjhWIc14RbJuGH48biBrw6ZA4XKG8sM83pzZN0StviRniqMzi
X46G+ejDauLtYGhzefjJDCcmcGqARfUs8G9FGbF9LzFD9QW/lDTwWCOFYBNbH1Xz
S00dakldm4YIIQMHmmoYGutQ6Hc71Z1rsmRRm9q0WNpO32ojDqqCEmbnOgi5kZs=
=yS8f
-----END PGP SIGNATURE-----

Received on Monday, 2 February 2015 23:14:30 UTC