Re: Shapes, Individuals, and Classes - OSLC Motivations

Hi Arthur,

thanks for the write-up. As others have said, I don't see why these 
scenarios cannot already be expressed in RDF Schema and owl:imports. 
What do you think about the solution with named graphs that I outlined 
in previous emails? Instead of asserting that stand-alone shapes are 
needed, why not first prove that existing approaches don't work?

We could provide worked-out examples if you could make your example more 
specific.

Thanks,
Holger


On 11/7/2014 6:01, Arthur Ryman wrote:
> Peter,
>
> I've created a user story [1] that describes "custom attributes" and
> related concepts. These concepts were not created by OSLC. Rather, OSLC
> was designed to accommodate this situation which is very common in
> software development tools and probably many other applications.
>
> For example, consider GMail Contacts. It defines several types of phone
> number (home, work, mobile), address (home, work), etc, but you can add
> custom types. You'd probably start with vCard as the RDF representation.
> Now suppose your company was using GMail, and that you could configure it
> with some additional types of phone number, and could specify the RDF
> property for those.
>
> [1]
> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S24:_Open_Content_Model
> _________________________________________________________
> Arthur Ryman
> Chief Data Officer
> SWG | Rational
> 905.413.3077 (phone) | 416.939.5063 (cell)
> IBM InterConnect 2015
>
>
>
>
> From:   "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> To:     Arthur Ryman/Toronto/IBM@IBMCA,
> Cc:     public-data-shapes-wg@w3.org
> Date:   11/06/2014 12:14 PM
> Subject:        Re: Shapes, Individuals, and Classes - OSLC Motivations
>
>
>
> I still don't know what "custom" means here with respect to RDF.  As far
> as I
> can tell any bit of an ontology, or class, or property, or constraint, or
> shape could be called "custom".  Now it may be that within OSLC there is
> some
> notion of custom vs non-custom, but how can that notion be removed from
> OSLC
> so that it can be used elsewhere?
>
> Similarly, the notions of "specification", "implementation", "project",
> etc.,
> appear to me to be specific to OSLC, and particular to the design
> methodology
> you outline below, and using them to drive a spec could, I think, tie that
>
> spec quite closely to the design methodology.
>
>
>
> As a contrast, here is what I believe should be used to say that classes
> and
> shapes/constraints are decoupled.
>
> Definition:  Classes and shapes/constraints are decoupled if the
> specification
> can use different sets of shapes/constraints on the same class.  For
> example,
> if the specification permits the ontology
>     ex:Person rdf:type rdfs:Class .
>     ex:name rdf:type rdf:Property .
>     ex:name rdfs:domain ex:Person .
> to be used with the constraint set
>     ex:Person < exists ex:name
> (every person has a "known" value for its name)
> or used with the constraint set
>     ex:Person < all ex:name xsd:string
> (all "known" names of people are strings)
> then it will be said to allow the decoupling of constraints/shapes and
> classes.
>
>
> A stronger notion would be that shapes/constraints are independent of
> classes.
>    This could be defined as:
>
> Definition:  Classes and shapes/constraints are independent if some
> shapes/constraints do not use class membership in their definition.  For
> example, the following constraint is class-independent:
>     exists ex:name < exactly 1 ex:name
> (if something has a "known" name then it has exactly one "known" name)
>
>
> peter
>
>
>
>
> On 11/06/2014 04:59 AM, Arthur Ryman wrote:
>> Peter,
>>
>> OSLC defines specification for RDF representation of resources in
> several
>> domains, e.g. Requirements, Quality, Change Management etc. A
>> specification typically defines a class and several properties.
>> Implementations are allowed to add new RDF properties but they don't
>> necessarily introduce new RDF classes. Furthermore, within an
>> implementation, users may add custom RDF properties on a
>> project-by-project basis, but that doesn't change the RDF class.
> Therefore
>> different projects use different Shapes but the Shapes only differ by
> RDF
>> properties, not RDF classes. That is what I mean by decoupling Shapes
> and
>> Classes.
>>
>> I will elaborate this on the wiki.
>> _________________________________________________________
>> Arthur Ryman
>> Chief Data Officer
>> SWG | Rational
>> 905.413.3077 (phone) | 416.939.5063 (cell)
>> IBM InterConnect 2015
>>
>>
>>
>>
>> From:   "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
>> To:     Arthur Ryman/Toronto/IBM@IBMCA, public-data-shapes-wg@w3.org,
>> Date:   11/05/2014 05:27 PM
>> Subject:        Re: Shapes, Individuals, and Classes - OSLC Motivations
>>
>>
>>
>> I'm still wondering what you think it means to decouple shapes and
>> classes.
>> The first motivation you provide is supported by both SPIN and OWL
>> constraints.  I can't figure out what custom properties have to do with
>> classes, or constraints, or shapes.  The behaviour you appear to be
>> looking
>> for in your second paragraph is also supported by both SPIN and OWL
>> constraints.
>>
>> I had thought that this was ironed out at the Face-to-Face, but I guess
>> not.
>>
>> peter
>>
>>
>> On 11/05/2014 01:47 PM, 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
>>>
>>>
>>
>>
>
>
>

Received on Thursday, 6 November 2014 22:58:43 UTC