Re: Shapes, Individuals, and Classes - OSLC Motivations

OK, so then it's not just RDF graphs, it's something else.  What is this else?

peter


On 11/07/2014 05:45 AM, Eric Prud'hommeaux wrote:
> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-11-06 20:36-0800]
>> So your view is that all that counts is the graph?  Nothing about
>> datatypes, or RDF, or RDFS?
>
> I suspect that OSLC wants datatypes, noting that Resource Shapes has
> an oslc:valueType predicate for identifying the datatype of a literal.
>
>    http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#valueType
>
>
>> 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 14:23:02 UTC