oeg-upm / auroral-core-ontology Goto Github PK

core:hasTemporalUnit (https://auroral.iot.linkeddata.es/def/core#hasTemporalUnit) appears in the adapters and core ontology images, but it doesn't exist. Please add it.

Hello, is it possible that the class core:Domain will be moved to be a child of core:Item??

Currently it is under core:Service (which is child of core:Item)

Hello,

I would like to include a data model for sensor measurements.
See below my proposal for standard JSON-LD for sensors:

{
@context: --> Sensors
@type: --> Sensor type (As for available types in VICINITY/AURORAL ontologies)
oid: string
iid: string --> interaction id: property or event id defined by user
timestamp --> We can follow some standard for the timestamp too
measurements: [
{
@propertyType: --> property type (From available properties in ontology)
value: number/string
units: string --> Should this follow an ontology? Example: celsius, meters, lumens...
},
...
]
}

I believe all fields should be mandatory, however, If it is possible, we can extend with optional fields for particular cases that might arise.
Please let me know if this should be extended or not feasible so we can adapt it.

Is there an ontology we can use for licensing data?
For instance specify if the date can be used for commercial uses or shared with third parties.
Something like the MIT or APACHE licenses for software.

Remove adapters class (the adapters is other ontology)

I would like to be able to specify serialNumber and/or versionNumber for my registered devices.

Currently we have name, description, hasManufacturer and hasModel.

Could you please provide an example of a service that is located in a place?

I can't access the following classes:

http://www.ontology-of-units-of-measure.org/resource/om-2/Decibel
http://www.ontology-of-units-of-measure.org/resource/om-2/metersPerSecond-TimeSauared
http://www.ontology-of-units-of-measure.org/resource/om-2/angularDegree
http://www.ontology-of-units-of-measure.org/resource/om-2/kilowattMeter
http://www.ontology-of-units-of-measure.org/resource/om-2/Percentage
http://www.ontology-of-units-of-measure.org/resource/om-2/kilowattYear
http://www.ontology-of-units-of-measure.org/resource/om-2/KiloWattSquareMeter
http://www.ontology-of-units-of-measure.org/resource/om-2/milliampereHour
http://www.ontology-of-units-of-measure.org/resource/om-2/ampereHour

The rest of the classes in the ontology-of-units-of-measure ontology are working. Can you verify these links?

Add the missing ontologies to table 1 (for example, the om, sosa or time ontology).

We need to check if the amount of values for these fields is finite by asking the partners. If that is the case, it could be a good idea to model them as named individual ?

Please see below the expected fields of a typical payload describing a charging station

{
    "IsRecentlyVerified": boolean,
    "DateLastVerified": date,
    "ID": long int,
    "UUID": uuid,
    "DataProvider": (Linked ID) { <DCTERMS>
      "rights": string, 
      "license": string
    },
    "Operator":   (Linked ID)  {
      "WebsiteURL": string,
      "PhonePrimaryContact": string,
      "PhoneSecondaryContact": string,
      "IsPrivateIndividual": boolean,
      "BookingURL": string,
      "ContactEmail": string,
      "Title": string
  },
    "OperatorsReference": string,
    "UsageType": (Linked ID) {
        "IsPayAtLocation": boolean,
        "IsMembershipRequired": boolean,
        "IsAccessKeyRequired": boolean,
        "Title": string
    },
    "AddressInfo": { <FOAF?? + GEO>
        "Title": string,
        "AddressLine1": string,
        "Town": string,
        "Postcode": string,
        "Country": (Linked ID) {
          "ISOCode": string,
          "ContinentCode": string,
          "Title": string
        },
        "Latitude": number,
        "Longitude": number,
        "ContactTelephone1": string,
        "ContactEmail": string,
        "RelatedURL": string,
        "AccessComments": string
    },
    "Connections": [
        {
            "StatusType": (Linked ID) {
              "IsOperational": boolean,
              "IsUserSelectable": boolean,
              "Title": string
          },
          "ConnectionTypes": (Linked ID) {
            "FormalName": string,
            "IsDiscontinued": boolean,
            "IsObsolete": boolean,
            "Title": string
          },
            "Amps": number A,
            "CurrentType": (Linked ID) {
              "Description": string,
              "Title": string
            },
            "Voltage": number V,
            "PowerKW": number kW,
            "Quantity": number
        }
    ],
    "StatusType": (Linked ID) {
      "IsOperational": boolean,
      "IsUserSelectable": boolean,
      "Title": string
    },
    "NumberOfPoints": number,
    "GeneralComments": string,
    "DateLastStatusUpdate": date,
    "DateCreated": date
  }

More info about the EV Chargers
https://openchargemap.org/site/develop/api#/schemas/POI

saref:Measurement has a relation (wot:hasValueType) with wot:DataSchema.

Why do we need this?

I was using the part of the core ontology for services and I realised there are fields that may be repeated. The core:Service is sub-class of wot:Thing, which specifies fields like td:title or td:description which are re-defined in the core as core:serviceName or core:serviceDescription.

To avoid partners defining these fields in two different ways, which may hinder discovery (especially in for the service store), I would suggest to check the repeated fields and maybe remove them from core.

add relation between measurement and property

We are missing adapterId in the core ontology, it should be a string property of a core:Item

It would be great to have a way to obtain the the classes hierarchy or related classes to each of the properties in a TD.
Options:
Consider adding endpoint to WoT Directory?
Query to the ontology?
Load the ontology on the WoT directory?

We can use https://saref.etsi.org/core/UnitOfMeasure to follow the SAREF ontology instead of the om ontology.

We can extend the class UnitOfMeasure from SAREF with the rest of the OM classes.

Identify the requirements and create a new ontology with this data:

{ userid: "[to be identified]", key: "[to be identified]", platform { type: "[to be identified]", list: "all" | "id", charger: "yes" | "no", charger-capacity: [to be defined], charger-capacity-unit: "watt", sensor: "[to be identified]" occupancy-status: "occupied" | "vacant" | "assigned" | "error" | "maintenance", capacity-weight: [to be defined], capacity-weight-unit: "kg", capacity-dimension: [to be defined], capacity-dimenstion-unit: "meter", description: "[add description]" }, drone { type: "[to be identified]", list: "all" | "id", priority: "[0-5]" storage-capacity: "yes" | "no", occupancy-status: "occupied" | "vacant" | "assigned" | "error" | "maintenance", capacity-weight: [to be defined], capacity-weight-unit: "gram", capacity-dimension: [to be defined], capacity-dimenstion-unit: "centimeter", sensor: "[to be identified]" description: "[add description]" }, mission { code: "[To be identified]", shipment: "[To be identified]", GPS-unit: "WGS84", from-pos: "[GPS]", to-pos: "[GPS]", waypoint-pos: "pos 1, pos 2, ..., pos n", from-platform: "platform id", to-platform: "platform id", waypoint-platform: "platform id 1, platform id 2, ..., platform id n", description: "[add description]" } }

Use the fields from TDs for these