Reusable Shapes (was: Shapes, Individuals, and Classes - OSLC Motivations)

I came late and this thread became so big that is hard to pick it up
properly.

I would like to raise another related issue regarding Shapes reusability.
Assuming I have X defined shapes and Y applications profiles that each
profile can reuse any of the X defined Shapes. Is this case something that
this WG would like to cover?
If yes, what would be the proper approach to store & define Shapes?

Best,
Dimitris

On Wed, Nov 19, 2014 at 1:19 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 11/19/2014 9:12, Eric Prud'hommeaux wrote:
>
>> * Holger Knublauch <holger@topquadrant.com> [2014-11-06 09:42+1000]
>>
>>> Hi Arthur,
>>>
>>> I am looking forward to seeing this worked out as a specific
>>> example. Currently I don't see why named graphs would not cover your
>>> use cases.
>>>
>> I suspect that by "named graphs" you mean using named graphs as a way
>> to perform course-grained instantiation and revocation. In Arthur's
>> example, this would mean when dealing with project A, load a named
>> graph that provides some constraints for an object. When dealing with
>> project B, throw away that first named graph and load another with
>> constraints for the same object. How does one deal with both at the
>> same time?
>>
>
> To deal with both contexts, just keep the named graphs separate at
> execution time. In Arthurs example, project A calls the CreationFactory
> servlet with one context, while project B calls it with another context.
> The CreationFactory assembles the graph that it needs *for this
> transaction* while the other transaction uses a different configuration of
> graphs by creating different union graphs and import closures. Why should
> they merge both graphs together? Transaction A would not even know anything
> about Transaction B. These are controlled environments, not "The (global)
> Semantic Web".
>
> Holger
>
>
>
>
>
>>
>>
>>  This topic is crucial to discuss exhaustively because it sits at the
>>> very foundation of the differences between ShEx/Resource Shapes and
>>> OWL/SPIN.
>>>
>>> Holger
>>>
>>>
>>> On 11/6/2014 7:47, Arthur Ryman wrote:
>>>
>>>> There are a few motivations for decoupling shapes and classes. One is
>>>> that
>>>> the creation shape may be different than the update shape. Another has
>>>> to
>>>> do with custom properties. I'll write up the following in the wiki.
>>>>
>>>> OSLC supports an open content model for resources. It is common for
>>>> tools
>>>> to add their own custom properties, and for projects within a tool to
>>>> have
>>>> different user-defined properties. For example, consider a bug tracking
>>>> tool. Project A may add a custom property foo and project B may add bar.
>>>> All projects use the same RDF type for bug resources, e.g.
>>>> oslc_cm:ChangeRequest. However, the shape for resources in project A
>>>> differs for the shape for project B.
>>>> _________________________________________________________
>>>> Arthur Ryman
>>>> Chief Data Officer
>>>> SWG | Rational
>>>> 905.413.3077 (phone) | 416.939.5063 (cell)
>>>> IBM InterConnect 2015
>>>>
>>>>
>>>>
>>>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas