Re: Shapes, Individuals, and Classes - OSLC Motivations

So your view is that all that counts is the graph?  Nothing about datatypes, 
or RDF, or RDFS?

peter


On 11/06/2014 12:01 PM, Arthur Ryman wrote:
> Peter,
>
> Commenting on your proposed wording of how to express the "decoupling"
> requirement. I'd go further and demote the notion of class to being more
> like just another property and view the shape/constraints as applying to
> the RDF representation of an information resource, i.e. to a set of
> triples (aka an RDF graph). Some of the triples will have rdf:type as the
> predicate and those triples are useful for locating certain subject nodes
> that we want to say more things about, e.g that they are the subjects of
> triples that have certain other predicates, etc.
> _________________________________________________________
> 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 Friday, 7 November 2014 04:37:19 UTC