Re: shapes and classes: different

I second Jerven's suggestion on more examples, because I believe some of 
the original motivations by a separate "Shapes" architecture can now 
also be covered by (LDOM) Contexts. So we should examine with an open 
mind what is left.

I also agree with Peter's second pattern of augmenting the notion of 
classes. I believe this can be compared to "punning" in OWL 2. Depending 
on the view point, a "class" should either be interpretable as an 
OWL/RDFS Open-World class, or as a "Shape" with closed world semantics. 
Syntactically they could be using the same URI and some of the same 
properties. This does not exclude that people could instantiate 
ldom:Shape directly if they prefer to, to make it more explicit that 
this shape should never be instantiated. (ldom:abstract=true would have 
the same effect).

Holger


On 2/3/2015 9:13, Peter F. Patel-Schneider wrote:
> -----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:28:33 UTC