OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (ODATA-696) Support "interfaces" for casting entities to multiple different types


    [ https://issues.oasis-open.org/browse/ODATA-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62734#comment-62734 ] 

Michael Pizzo commented on ODATA-696:
-------------------------------------

When we discussed on 2016-6-16, folks were interested in understanding the scenario for this.  Here is a use case based on a real-life scenario where this came up:

An IOT team was attempting to use OData to model intelligent vehicles.
Vehicles have their own hierarchy:
Vehicle
Car : Vehicle
Motorcycle : Vehicle
Truck : Vehicle
etc..

Some vehicles are "smart" vehicles. Those that are can be treated as an "IOT.SmartDevice" with properties for "manufacturer", "model", "version", "ipaddress", etc. describing the vehicle as a device (not as a vehicle -- i.e., "model" would be model of the IOT device, not of the vehicle).

Similarly, escalators, light bulbs, thermostats, etc. can all be "smart", meaning that they implement the same IOT.SmartDevice properties.

Sometimes I want to look/interact with a vehicle as a vehicle (and not see properties of smart device, especially for vehicles that are not smart), other times I want to look at/interact with it (or an escalator, or a light bulb) as an IOT.SmartDevice.

Allowing clients to cast a vehicle, escalator, or lightbulb to IOT.SmartDevice enables me to interact with a variety of such devices through a common class, without smart device being part of the hierarchy (since many vehicles are, unfortunately, not so smart).

Similarly, I could cast EV vehicles (along with phones, laptops, battery-powered chain saws, etc.) to "ChargedDevice" to get this like capacity, max input, max ouput, etc. Or any one of dozens of other types to interact with contextually. 

The existing rules for cast work great for this.  Just as I can cast vehicle to a motorcyle in order to deal with it as a motorcycle, so could I cast a vehicle to a smart device in order to treat it as a smart device. And, just as treating a collection of vehicles as motorcycles filters out those vehicles that are not motorcycles, so would treating a collection of vehicles as smart devices filter out those vehicles that are not smart devices. 

There are a few differences;
1) A motorcycle inherits all of the properties of the base type (vehicle).  That's not necessarily the case when casting to an "implemented class".  This is fine, though, because, by declaring "Vehicle" as a base type, "Motorcycle" is saying that it has all the properties of a vehicle.  Since "SmartDevice" doesn't derive from "Vehicle", clients wouldn't expect it to have the properties of the base type.
2) Similarly, the derived type cannot change the definition of a property in the base type. Which again makes sense because type derivation means that the derived type has all the properties of, and can be treated as, the base type. Any Motorcycle can be treated as a Vehicle. Not all smart devices can be treated as a vehicle, and not all vehicles can be treated as a smart device.

Ralf also brought up our current rules about structural casting between types.  Thinking about this more, I realized this type of structural casting is very dangerous.  If I have a type "Person", with two derived types "BankingCEO" and "Criminal", both with properties "Institution", "PositionSince" and "Term", do I really want to cast one to the other?  Treating a criminal as a banking CEO isn't fair to the criminal. Even worse, do I want applying a cast segment to a collection to support this structural cast?  Often times derived types are implemented as marker interfaces for identification purposes only, and contain no additional properties. Structural casting wouldn't distinguish these types, so if DeathRowCriminal trivially derived from Criminal and I did ~/Criminals/JusticeSystem.DeathRowCriminal to schedule executions, I would end up scheduling all of the criminals, not just those that were actually supposed to be on death row.  And ~/People/JusticeSystem.DeathRowCriminal would include banking CEOs, which may not be all bad, but you'd probably want to prioritize the CEOs before the murders.

So I would proposed we get rid of the structural casting, or at least clarify that it doesn't apply to filtering collections, only in comparisons.

Either way, though, I don't think the concept of "interfaces" is entirely incompatible with structural casting.  We could simply say that structural casting is the default, if the service doesn't implement some other casting semantics to the specified type.

> Support "interfaces" for casting entities to multiple different types
> ---------------------------------------------------------------------
>
>                 Key: ODATA-696
>                 URL: https://issues.oasis-open.org/browse/ODATA-696
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData CSDL, OData URL Conventions, Vocabularies
>    Affects Versions: V4.0_OS
>         Environment: Interfaces
>            Reporter: Michael Pizzo
>            Assignee: Michael Pizzo
>            Priority: Minor
>              Labels: Extension, GoodIdea
>             Fix For: V4.01_WD01
>
>
> OData's single-inheritance type model works well for many types of ontologies where new types are specializations of existing types, and maps well to class definitions in popular programming languages. However, single inheritance does not describe the fact that an instance of a type can play multiple different roles.
> Vocabularies were introduced to OData in order to enable the definition of common schemas that could be shared across a particular industry or enterprise. Vocabularies allow the ability to share semantic information, such as the fact that a particular instance represents some generic concept.
> Entity models can use these shared schema in defining a data model, for example through derivation, or can map properties of a defined entity to properties of an entity from a shared model. However, we don't have a common way for a service to specify that an entity can be treated (i.e., cast) to another entity outside of the single-inheritance hierarchy, and requiring inheritance to model ontologies is overly restrictive in many cases. Also, some ontologies (like schema.org) make use of multiple inheritance, making it difficult for an entity to derive, for example, from both an individual and an organization.
> Odata defines clear semantics for casting entities of one type to a different type in requests urls, filters, etc. Services can support casting instances to any type, but can currently only advertise the ability to cast to a single (derived) type.
> Adding a new "implements" annotation term to the Core vocabulary allows a service to advertise the fact that one type can be cast to one or more other types using existing cast rules. This rule is entirely backward compatible; it doesn't introduce any incompatible behavior and is entirely safe for a client to ignore.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]