OSLC Core Meeting December 8, 2010
Last week's meeting
Link to OSLC Core spec:
OslcCoreSpecification
Meeting logistics
How to dial-in to our telecon and login to our screen-sharing session (when we need it).
Telecon Info
- USA Toll-Free: 888-426-6840
- USA Caller Paid: 215-861-6239
- Participant Code: 6867265
Online meeting
(when we need it)
- For IBM employees, use the following link:
- For people outside IBM, use the following link:
Agenda
Multi-typed resources, Jim Conallen
There will be cases where a resource is of multiple rdf:types but we have no guidance on how this situation should be handled. Jim will lead a discussion to explain the related scenarios, the open issues and his recommendations for Core and/or other Domain work-group activities around this topic.
Examples and some point for discussion:
http://open-services.net/bin/view/Sandbox/MultiTypedResources
Minutes
Attendees and notes from the meeting
Attendees
Topics discussed
Below are my notes from the meeting - Dave
Jim
We've always said that resources can have multiple types
We've done a good job on specifying cardinality of types
But there are open issues and in AM we need multiple types
Here is an example of a multi-typed resource, both an AM and RM resource
Scott:
Can we start by talking about the general concept of multi-typed resources
What is a type, is it simply another property?
Dave:
That's how I see it
Arthur:
It depends on how you are defining ontologies, we are less formal
You guys are starting to use OWL, no?
Jim:
Yes, but not as part of OSLC work
I had assumed that resources that include OSLC types, follow OSLC semantics
Arthur:
No, anybody could put a type in a resource, that does not mean resource complies with spec
Jim:
If you cannot infer spec semantics, or properties then what good is a type
Jim:
Is provider allowed to support multiple specs simultaneously?
It is certainly possible
If I want to create an AM resource, I look for a factory that allows it
If I want a multi-type resource, I look for a factory that supports both types
But of course, that would work only if the implementor specifically allows
Dave:
How do you implement this in terms of service discovery resource?
Jim:
Provider provides two services, one for AM one for RM
(couldn't keep up with conversation here)
Ian:
What about the case where two specs define a common property differently?
We've split things up, now we have to bring them back together
Domain specs "own" their usage of common properties, this may be a problem
We shouldn't allow two specs to define different mean to common properties
(couldn't keep up with conversation here)
Arthur:
If we provided an ontology, then we could do type to property inferences
Arthur:
You cannot infer that a resource with a type follows our specs
The only time you can expect resource to behaved as specified is when you get it from an service that implements a specification
Steve:
Just because a creation factory lists two types does not mean it supports multi-typed resources
Dave:
This is a deep topic and we need more time to discuss
Possible ways to address:
- Change structure of OSLC specs, have one Core spec, and resource definitions for each domain
- Introduce Ontology tools such as OWL so properties can be inferred from types
- Changes to the way we handle common properties
- Guidance on Multi-typed resources
AI: Dave and Jim to discuss next steps