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

On Nov 19, 2014 12:28 PM, "Dimitris Kontokostas" <
kontokostas@informatik.uni-leipzig.de> wrote:
>
> 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?

We have, if I recall, accepted requirements to have both reusable shapes
and reusable rules within those shapes. So far, all of the proposed
technologies enable that, though of course we'd want to then consider
practical ways to overload, extend, and maybe even retract parts of reused
rules.

> 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