Re: Shapes, Individuals, and Classes - OSLC Motivations

Holger,

I am not following your suggestion. Please clarify at the telecon 
tomorrow. My brief response is:

RDFS does not express constraints. 

owl:imports has semantics defined by the OWL spec, which does not express 
constraints. 

I don't see how named graphs apply. In OSLC, we follow Linked Data which 
means resources have RDF representations, i.e. sets of triples. Named 
graphs are part of RDF Datasets so you'd need to use Trig or N-Quads.
_________________________________________________________
Arthur Ryman
Chief Data Officer
SWG | Rational
905.413.3077 (phone) | 416.939.5063 (cell)
IBM InterConnect 2015




From:   Holger Knublauch <holger@topquadrant.com>
To:     public-data-shapes-wg@w3.org, 
Date:   11/06/2014 05:58 PM
Subject:        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 Tuesday, 11 November 2014 21:45:30 UTC