search

w3c / sdw-sosa-ssn

Repository of the Spatial Data on the Web Working Group for the SOSA/SSN vocabulary
9 stars 5 forks source link

System types and individuals #107

Closed maximelefrancois86 closed 1 week ago

maximelefrancois86 commented 1 year ago

It is still unclear when one wants to model a generic kind of system (aka, model, category, class, ...), whether they should model it as an instance of ssn:System, or a subclass of ssn:System.

As ssn:System is a superclass of sosa:Sensor, sosa:Actuator, sosa:Sampler, this confusion also applies to these class.

This ambiguity is reported in https://www.w3.org/TR/vocab-ssn/#SSNSystem-instances

In the SOSA/SSN examples, systems/sensors/actuators sometimes model generic sensor kinds, and sometimes a unique actual instance of sensor:

It would help a lot to be able to identify kinds of systems generically, the same way we do with property kinds. One advantage would be that we could reuse existing code lists, vocabularies, and taxonomies. Identifiers could be for example:

Another advantage is that it would encourage manufacturers and vendors to define permanent URIs for their devices, and to expose structured data at the page that describes a device in a catalogue. Some examples of product IDs from manufacturer and vendor catalogues:

My proposal to disambiguate the concept while maintaining backward compatibility with previous usages would be to split ssn:System in two classes:

sosa:SystemOfInterest

System is a unit of abstraction for real-world pieces of infrastructure that implement Procedures. A System may have components, its subsystems, which are other Systems.

By the way, we should extend this definition to account for use cases when one wants to identify the digital twin of a system using that same class in SOSA (the digital model of a system of interest is also a system of interest).

sosa:SystemKind

An instance of sosa:SystemKind describes a datasheet, vendor specification, or normative specification, of a sensor (in the sense of a prototypical description).

EXAMPLE: system with European Union energy label A++ , Energy Star labeled appliance, BMP282, DHT22, Adafruit 5187, ...

NOTE: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of sosa:SystemKind.

NOTE: alternative names could be: sosa:SystemModel, sosa:SystemType, ...

dr-shorthair commented 1 year ago

@alexrobin @KathiSchleidt do you have an opinion on this?

alexrobin commented 1 year ago

@maximelefrancois86 At the moment, we are using Procedure to provide the datasheet of a System since we consider that the datasheet is the specification that is implemented by the Systeminstance. I think it is the intended usage when the system is a piece of hardware equipment.

@KathiSchleidt @dr-shorthair Can you comment on this usage of Procedure?

If Procedureis indeed intended to be used in this way, then I think we either don´t need a new SystemKindclass or, if we introduce the new class, it should probably be a subclass of Procedure.

dr-shorthair commented 1 year ago

@alexrobin at first sight at least that is a reasonable approach.

maximelefrancois86 commented 1 year ago

@alexrobin I'm not convinced at all.

The spec itself mentions that ssn:System can be used to generically refer to a type/kind of system. So it shouldn't be an option to suggest an completely alternative way to model is.

What's more, Procedure describes receipes. It's aligned to dul:Method. oldssn:Process, OM_Process, oboe:Protocol, prov:Plan ... I don't think it's appropriate to use this class to describe the capabilities and other characteristics of the system.

If I model the DHT22 temperature and humidity sensor type as a kind of sosa:Sensor, then I model the fact it observes temperature and humidity using the sosa:observes property. If instead I model this sensor type as a kind of sosa:Procedure, then I cannot link it to the temperature and humidity properties. Some systems/sensors implement more than one procedure, although they are described in exactly one datasheet.

alexrobin commented 1 year ago

@maximelefrancois86 I actually agree with you. I have never really liked the idea of using Procedure to describe a "kind of System" but I have been told by the OMS/O&M group that it is way we should model it. Since I didn't want to reinvent the wheel, I decided to go with that approach.

You're right that the link between Procedure and ObservedProperty is missing, but this addition has been requested in issue #47 (Note that it was originally requested by @sgrellet).

maximelefrancois86 commented 1 year ago

While discussing for the new version of ETSI SAREF with @rgcmme , it was agreed to keep only two classes. In particular, to avoid having a common super-class that we hope nobody will use.

As sosa:Device is most commonly used to represent actual devices, not types/kinds of devices, we would keep it for this purpose.

For the class that models device types/kinds , different proposals were made:

DeviceKind / Type / Model / Category /Specification / Prototype / ...

After some discussion with @dr-shorthair , only DeviceKind / and DeviceType are good candidates. They are the most generic ones. Some considerations:

alexrobin commented 1 year ago

@maximelefrancois86 is sosa:Device defined somewhere? I cannot find it in the current draft. Are you referring to the ssn:Device class that existed before the alignment with SOSA?

I liked your idea of having SystemKind, although I would like to have the ability to provide capabilities and characteristics of platforms as well (and Platform is NOT a System in the current ontology, which I find a bit strange...).

Thanks,

maximelefrancois86 commented 12 months ago

Device is from SAREF. I mixed this up a bit.

Please read: sosa:System, sosa:Sensor, sosa:Actuator, sosa:Sampler, would be for the actual systems, And: sosa:SystemKind, sosa:SensorKind, sosa:ActuatorKind, sosa:SamplerKind for the kinds/types.

Indeed we could also differentiate Platform vs PlatformKind

In SOSA Platform is NOT a System because it was decided not to define subclasses. We could have added that axiom in SSN, but we didn't. I wouldn't be able to explain why. This may be the object of a separate issue?

alexrobin commented 12 months ago

@maximelefrancois86 Ok, that makes sense to me.

@dr-shorthair what are your thoughts on this? Is using Procedure to provide datasheet type info (i.e. system characteristics and capabilities) still considered good practice or should we move to the SystemKind approach in addition to Procedure?

rob-metalinkage commented 12 months ago

Device characteristics are not part of a procedure. I saw recently a case where the identical open source sensor was used to measure ostensibly the same feature type (air quality in a room) but significant differences in procedure resulted in incompatible data.

One aspect of the difference was standardisation of siting - arguably this is nuanced sampling etc, but the point is differences in level of abstraction in one dimension tend to result in shifting the specialisation to another, finer grained semantics between instance and kind seems to be a pattern that helps.

I also wonder about FoIKind . If a referenced feature is polymorphic is it important to understand the context and which view of that feature has the relevant properties if you want to make an observation on the state of it...

alexrobin commented 12 months ago

@rob-metalinkage Yes, as I said I tend to agree with this (it actually solves some of my problems), but be aware that the OMS v3 conceptual model kind of hints at using the Procedure class to describe sensor/observer types.

From https://docs.ogc.org/as/20-082r4/20-082r4.html#_observingprocedure

NOTE 5: The observing procedure cannot describe a sensor instance, but it can describe the sensor type.

From https://docs.ogc.org/as/20-082r4/20-082r4.html#_observer

NOTE 2: The Observer is the entity instance, not the entity type. Pertaining to sensors, the Observer would reference the explicit sensor, while the Procedure would reference the methodology utilized by that sensor type.

And I clearly remember discussions with the OMS folks where they recommended using the Procedure class to describe a sensor "datasheet". @KathiSchleidt @sgrellet Am I wrong, could you comment on this?

sgrellet commented 12 months ago

@alexrobin : indeed, the underlying rationale in OMS was

to try and desambiguate what people were doing with OM:OM_Process (depending on communities/best practices it was either used for Sensor Types or for Sensor Instances)

alexrobin commented 12 months ago

Thanks for the confirmation @sgrellet. That's what I understood from our conversations and I thought having two separate classes Observer and ObservingProcedure was a great improvement over OM_Process.

However, apparently there is still ambiguity between Procedure to describe a methodology and Procedure to describe a sensor type (i.e. datasheet). And it's true that in many cases one uses a sensor of a particular type, but also follows a certain procedure to use that sensor. So you end up with two Procedures (if we follow the OMS definition of Procedure).

The way I have solved this in Connected Systems is by attaching one Procedure to the Observer/Sensor instance (this one describes the sensor type) and another Procedure to the Deployment to describe how the sensor is used in that particular deployment (i.e. the methodology).

I like the new proposal for new ***Kind classes, but how do we reconcile the semantics?

dr-shorthair commented 11 months ago

Could we just allow more than one usedProcedure link on an Observation/Actuation/Sampling activity? Else retain the [1..1] cardinality but define a 'Procedure container' which in turn refers to both a datasheet and a methodology?

ldesousa commented 10 months ago

I would rather retain the [1..1] cardinality, but I would still see the "Procedure container" option as less than optimal. The case that @alexrobin described makes me wonder if instead we are missing something such as a SensorSetup class, to be instanced with e. g. a datasheet, wavelength interval, etc. The term "procedure" conveys a somewhat different concept, in my view.

rob-metalinkage commented 10 months ago

This is the same pattern we see for every dimension of the problem. IMHO symmetry will reduce complexity, so what we do for observed property should also apply to procedure, sensor, and perhaps metadata such as result, foi type etc.

IMHO we should describe the requirements, the pattern, and then the places it is applied in a separate section.

Let's do this first before risking different solutions and naming.

There are at least three layers...

The semantics of kind, with relationships between levels of generalisation

The implementation metadata the user needs.. I.e. the schema and data model used to describe the description

The instance

It's analogous to Web links, where we are inheriting rather adhoc mixtures of solutions to these when we come to schemas, generalised links, feature Type, features Schema properties etc.

alexrobin commented 10 months ago

@dr-shorthair I think the [1..1] cardinality on usedProcedure in Observation/Actuation/Sampling is fine if we only use this association to specify the procedure/method used for this particular obs, but not to point to a procedure/datasheet.

The datasheet is something that is mostly associated to the system itself because it is usually provided by the manufacturer and assumed to be valid no matter how the system is deployed or used (although some elements in the datasheet can be specified for different deployment conditions). So I don't think there is a real need to associate the datasheet to the Observation/Actuation/Sampling directly. One can get to it transitively through the System instance.

Perhaps we just need to clarify that the implements association on System can point to a different Procedure than the one on the Observation/Actuation/Sampling generated by that system? Although it is not clearly said, I think now there is an assumption that everything would link to the same Procedure.

This would handle the use case where the System represents a hardware device and points to the procedure/datasheet using the implements link, while the Observation/Actuation/Sampling (or an entire collection of these) references the procedure/method using the usingProcedure link.

In the case where the System represents a human observer, then perhaps the datasheet does not make sense so both links would point to the same Procedure.

I still like the SystemKind proposal, but this would be a way to make this work better without having to introduce new classes.

dr-shorthair commented 10 months ago

Thanks @alexrobin

As I don't work in this part of the space much, I'm finding it a bit hard to follow. Would it be possible to generate (or point to) some examples to support the approach(es) that you are describing?

TBH I'm very happy to be guided by you and @maximelefrancois86 who I think have the most experience in this space. If it involves new terms, then that's OK providing we have evidence of implementation for any normative terms. However, also note that I won't be able to generate either the sections in ssn/index.html or the definitions in ssn/integrated/sosa.ttl, ssn.ttl, ssn-system.ttl etc, so resolving this will depend on you guys doing the work and preparing the PR(s).

alexrobin commented 10 months ago

@dr-shorthair Sorry I think trying to explain things in plain English makes things confusing :-) Or maybe I don´t speak English correctly !

It boils down to the following. We currently have the following association chains:

Observation ---- madeBySensor  ----> Sensor ---- implements ----> Procedure (1)
          |----- usedProcedure ----> Procedure (2)

Is there a requirement that Procedure (1) is the same as Procedure (2) ?

If not, then this could be a way of specifying the methodology used separately from the sensor specs (datasheet), by pointing to 2 different Procedure instances:

The same applies to Actuation and Sampling since we have the following association chains:

Actuation ---- madeByActuator ----> Actuator ---- implements ----> Procedure (1)
        |----- usedProcedure  ----> Procedure (2) 

Sampling ---- madeBySampler ----> Sampler ---- implements ----> Procedure (1)
       |----- usedProcedure ----> Procedure (2)
alexrobin commented 10 months ago

Maybe that's how it was always intended to be used but I don't think it clearly says this anywhere...

dr-shorthair commented 10 months ago

Thanks @alexrobin - I'm cogitating on it. There should be a relationship between Procedure (1) and Procedure (2) I think?

alexrobin commented 10 months ago

@dr-shorthair Yes, there is some kind of relationship for sure. I would say that Procedure (2) always involves Procedure (1) in some way, if it is set. I see mostly 2 cases:

I think we can do all this with the current model, so perhaps initially, simple clarifications in the documentation could suffice. But creating subclasses of Procedure such as SystemSetup/SystemKind, SensorSetup/SensorKind, ActuatorSetup/ActuatorKind, SamplerSetup/SamplerKind would certainly clarify things.

@ldesousa @maximelefrancois86 @sgrellet Does it make sense to you guys?

sgrellet commented 10 months ago

+1 on relationship between Procedure (1) and Procedure (2) I think

Overall, I feel that we are entangled in that discussion in

I've seen above the mention of

What do we want here ?

=> Could we discuss this during a webconf with an example (and drawings to help abstraction) ?

alexrobin commented 10 months ago

@sgrellet All good points. I know OMS does not go as far as describing datasheets but SSN kinda does already by defining System Capabilities.

To me, the idea of a "SensorKind" is just to factor out some of these capabilities so they can be reused by many instances of the same sensor model, instead of repeating them in each instance. It's different from sensor type that is usually just a classifier.

That said, I don't necessarily expect SOSA/SSN to provide everything to specify datasheet level info, but what I would like is that the SOSA/SSN model clearly identifies the place where this information should be provided (i.e. in what class and via which association), and how it works when a procedure/methodology is also provided.

As mentionned by @maximelefrancois86 at the beginning of this thread, there is clearly some confusion right now since the ssn:System class (or the derived classes sosa:Sensor, sosa:Actuator, etc.) is sometimes used to describe a system kind (i.e. datasheet), and sometimes used to describe a system instance.

My understanding was that this issue was solved in OMS by separating out the Observer (equivalent to sosa:Sensor) and Procedure (equivalent to sosa:Procedure) concepts. What I discovered here is that not everybody is aligned on that approach and since it's not documented in SOSA/SSN, it is still up to interpretation.

KathiSchleidt commented 10 months ago

In OMS, we skirted by the datasheet issue by ignoring it, letting users provide a reference in the Observer if they wish. But I've always worried a bit about this omission, do think we need all 3 levels of:

What's still unclear to me from the discussion above are the relations to/between these concepts. I've done a quick sketch from some existing diagrams to illustrate the various cases described above (e.g. a human observer not having a datasheet, a sensor implementing 2 different procedures) we can use to discuss this evening

alexrobin commented 10 months ago

@KathiSchleidt I agree with you but now that we are talking about all this, I think I'm unclear about what "A sensor implements a procedure" even means.

I always thought in the case of a sensor device, the implements association was intended to point to the datasheet...

It's clear to me that a "human sensor" can implement a procedure, but how can a piece of hardware implement a procedure that's not already specified in its datasheet?

I'm also unfamiliar with the use case "a sensor implementing 2 different procedures". How can a sensor device implement two procedures at the same time? Are we talking about cases where a sensor has different modes? Where the sensor is highly programmable? Can you give a concrete example of this?

I can clearly see cases where a human implements a procedure that may involve a sensor, but it's not the same as the sensor itself implementing a procedure.

Just trying to connect the dots before I start drafting some ideas in the PR.

Thanks,

rob-metalinkage commented 10 months ago

Seems clear semantics of implements is too vague.

For example, I like conformsTo for the second case mentioned, needing to know some externally defined set of constraints are applied, but finer details also needed. I don't feel implements is good for a datasheet, hen rdfs:describedBy is available and feels closer.

It does run into the issue of a meta-description.. is it the description or described object that conforms, etc... ?

Maybe we need to tabulate options, document why we reject some, clarify meta description semantics

Allowing scalability of description detail whilst common patterns are constrained is the goal.

dr-shorthair commented 10 months ago

Could you all document these patterns?

I suggest doing this in a new sub-section in section 7 'Common modeling questions'. This should allow us to either converge or expose the variations and ambiguities.

I've added a stub to ssn/index.html in a branch for you all to work on.

See https://github.com/w3c/sdw-sosa-ssn/blob/systemkind-datasheet/ssn/index.html#L8639 permalink

hylkevds commented 10 months ago

On one end of the spectrum, for simple IoT sensors, the datasheet has all information available. On the other end of the spectrum, getting into the range of laboratory equipment, one device can measure many different things, using many different procedures.

Take for example something common like HPLC or Gas Chromatography used for chemical analysis. The datasheet of a GC will state things like:

For interpreting the Observations coming out of it, this is not very useful. The Procedure on the other hand contains the actual details:

Each measurement made on the same device may use a different procedure.

It's been more than 20 years since I used one of these in a lab though, so my memory of the exact details is a bit rusty.

alexrobin commented 10 months ago

@hylkevds Thanks for providing a good example.

We have similar use cases indeed but that's not how I interpreted the implements association.

My opinion is that the implements relationship that connects a System with a Procedure is not appropriate for these use cases involving operational procedures because such procedure is not permanently associated with the equipment. (and also because IMHO it's not really the system that implements the procedure, but rather the operator of the system).

I can see how one could add many implements associations to point to all possible procedures ever used to operate a given piece of equipment but I don't know how useful that is. I think the usedProcedure association on an Observation or ObservationCollection is a better place to record this type of information since it can potentially change for every obs made by the same equipment.

So, I think we should deprecate the implements association and add a new one (perhaps ofKind or hasKind?) that associates a System to a SystemKind.

Also, something that makes sense to me, is to have an (optional) association linking the Procedure to the SystemKind since such operational procedures would often be specific to a particular kind of equipment.

Of course, the same applies to Sampler/Sampling and Actuator/Actuation.

Would you agree? If so, I will draft a PR in that sense.

alexrobin commented 10 months ago

I guess, although the term "implements" is a little bit misleading, we don't have to deprecate the implements association if people are using it. I will simply clarify how it's supposed to be used in the PR (vs. the new association pointing to a SensorKind).

hylkevds commented 10 months ago

I don't see a difference depending on who programs the device to execute a certain procedure - the hardware designer, the software engineer or the operator. In the end, the device executes the procedure. In the case of a HPLC or GC device, the analyst only prepares the sample and then selects the procedure to be run on the sample. The same procedure may be implemented by many different brands of hardware with different specifications.

Having a list of all procedures that each piece of hardware can execute is very important for lab planning. Devices are always overbooked, and everyone wants to use the newest kit. So it's kinda handy to be able to quickly find an alternative device if you have a rush-job and your colleague just loaded a massive batch of samples in your favourite machine :)

alexrobin commented 10 months ago

Ok, I will NOT deprecate implements and document its use for that purpose then. Thanks.

I think we need to emphasize that the implements property really means "can implement" (i.e. we use it to point to all the procedures that the system can implement, not the procedure that it actually implements at any specific time.

alexrobin commented 10 months ago

@KathiSchleidt @sgrellet Are you ok not using Procedure to describe a sensor type / sensor kind ?

OMS has this note in section 8.5.2.

NOTE 5: The observing procedure cannot describe a sensor instance, but it can describe the sensor type.

And Sylvain had confirmed in this post that the intent was to describe sensor types/datasheets.

Should we keep SensorKind as a subtype of ObservingProcedure?

Or would you rather a clean separation between the two?

hylkevds commented 10 months ago

I think part of the confusion is because of different semantic use of the term sensor type.

The two are related, since the data sheet should contain the procedure information, but of different granularity. Both types of information are useful in different use cases, so ideally both should be clearly expressible without confusing the two usages. Adding a dataSheet concept as Sylvain suggested may not be a bad idea.

dr-shorthair commented 10 months ago

As mentioned above

Could you all document these patterns?

I suggest doing this in a new sub-section in section 7 'Common modeling questions'. This should allow us to either converge or expose the variations and ambiguities.

I've added a stub to ssn/index.html in a branch for you all to work on.

See https://github.com/w3c/sdw-sosa-ssn/blob/systemkind-datasheet/ssn/index.html#L8639 permalink

alexrobin commented 10 months ago

@dr-shorthair Yes, I will document what we are currently doing in Connected Systems in the stub you created. But I also wanted to understand where others are coming from...

KathiSchleidt commented 8 months ago

Where have we landed on this thread? We started with a proposal for sosa:SystemKind and sosa:SystemOfInterest, then devolved into discussions (that do highlight a requirement for a differentiation between the system type vs. instance, parallel to Property)

To my view, would make sense to do a parallel of sosa:Property vs. sosa:PropertyOfInterest, do we need sosa:SystemOfInterest?

Relevant to #201 , description under 8.6 Generic or Specific Instances of sosa:System

maximelefrancois86 commented 8 months ago

Parallel to how things are modeled in SAREF, I would recommend sosa:System and sosa:SystemKind. In fact, it's common that saref:Property is used to describe "generic" properties, but it's as common that saref:System is used to describe "specific" systems. Therefore, we believe it's more appropriate to introduce sosa:SystemKind instead of sosa:SystemOfInterest.

alexrobin commented 8 months ago

I second @maximelefrancois86's proposal of adding sosa:SystemKind rather than sosa:SystemOfInterest.

dr-shorthair commented 8 months ago

I won't have time to implement this. Can one of you guys prepare a PR?

alexrobin commented 8 months ago

I can work on a PR but I see two possible approaches:

  1. We add only SystemKind and in order to define a "type of system", we create a class that is both a SystemKind and a Sensor, Actuator, Sampler or Platform.

  2. We add SystemKind, but also derived classes SensorKind, ActuatorKind, SamplerKind, PlatformKind.

Option (2) is a little redundant but also clearer I suppose.

With option 1, I think the documentation of Sensor, Actuator, Sampler and Platform can stay as-is.

With option 2, I think it should be updated to say that these classes should only be used to describe "instances" of these systems and NOT "types", and that one should use the ***Kind classes to describe "types".

I believe we also need at least one property to reference the "kind" from the instance.

maximelefrancois86 commented 8 months ago

I like option 2 better, it separates clearly what class must be use to describe instances, and what class must be used to describe types Considering there exists property hasPropertyKind that links a PropertyOfInterest to its Property,
I suggest we introduce property hasSystemKind to link a System to its SystemKind.

alexrobin commented 8 months ago

@maximelefrancois86 sounds good to me.

Another change that I think should be made is to allow the properties in the system capabilities module to be used on the "***Kind" classes. Are you OK with this?

Any other opinion before I start working on the PR?

maximelefrancois86 commented 8 months ago

Yes this sounds reasonable

rob-metalinkage commented 8 months ago

The kicker is implementations being available l any plans?

alexrobin commented 8 months ago

@rob-metalinkage This will be integrated into OGC API - Connected Systems - Part 1 for sure

dr-shorthair commented 6 months ago

'datasheets' (i.e. *Kind classes) are perhaps an extension of scope to SSN Ontology. Maybe better in an extension module? (comparable to ssn-system: module)

dr-shorthair commented 6 months ago

I second @maximelefrancois86's proposal of adding sosa:SystemKind rather than sosa:SystemOfInterest.

Could this be added to ssn-system: rather than sosa:? https://w3c.github.io/sdw-sosa-ssn/ssn/#System-capabilities

dr-shorthair commented 5 months ago

This issue was discussed at length in the 2024-06-12 telecon. See comment on proposal to move System Capabilities to a separate document.

Reflecting on this a bit, we must also remember there are at least three kinds of system (sensor or actuator or sampler)

  1. hardware
  2. software (simulators)
  3. wetware - people as sensors

For case 1., hardware systems , there is usually a spec-sheet for a system type with a model number. Then individual instances each have a separate serial number. In most applications we want to know the type (and its specification) and rarely have any interest in the individuals.

For case 3., people, on the other hand, the type is 'trivial', and in most applications we only care about the individual.

For software , each instance is typically an exact clone - though there is a lot of nuance here.

I think I would like to propose that in the context of SSN/SOSA - a general purpose ontology - we specify that for hardware systems, the sosa:System class (and the specializations sosa:Sensor, sosa:Actuator, sosa:Sampler) relate to system types, as described by a spec sheet.

(The alternative - sosa:System is the class of individuals - would lead to a mass of singletons with limited utility in an information graph.)

If an application does have a need to describe individual systems in detail (SystemOfInterest?), then this should be an extension, and is beyond the scope of the core of the SSN Ontology (i.e. the sosa: namespace).