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

• Other numbers:
  • https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=6867265&accessNumber=2158616239

Online meeting

(when we need it)

• For IBM employees, use the following link:
  • https://lli.ibm.com/meeting/join/?schedid=4446009 (IBM intranet authentication required)
• For people outside IBM, use the following link:
  • https://apps.lotuslive.com/meetings/join?id=4446009

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

• DaveJohnson
• JimConnallen?
• NickCrossley
• ScottBosworth
• SteveSpeicher
• IanGreen
• ArthurRyman

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