Multiple Domain Properties entries?

[flomickl]

Hi,

I had a look at the domainProperty entry in the event schema.
It is stored as a ArrayList, but most methods creates it as a simple String URI entry.

In the required Stream process, you can only ask for single String domainProperty in the methods
https://cwiki.apache.org/confluence/x/i5NbDg

In the EventPropertyBuilder it is also just a single String
https://cwiki.apache.org/confluence/display/STREAMPIPES/01+Data+in+StreamPipes+%7C+Event+Properties#id-01DatainStreamPipes|EventProperties-EventPropertiyPrimitiveBuilder

But some methods in the EpProperty have a List Options

https://cwiki.apache.org/confluence/display/STREAMPIPES/01+Data+in+StreamPipes+%7C+Event+Properties#id-01DatainStreamPipes|EventProperties-EpProperty

It is intended to use multiple domainProperties?

An Example in the Geo Processors.

An Event can be a Geometry domain
but also be a Point

So I would like to add geometry and point as a vocabulary
If I have a processor, that asked for a geometry, I still can use it.
But if I have a processor that requires a Point, it is also valid

Although, you need then another method to read the ArrayList as well?

I think there are also some other examples not related to geo ;)

[tenthe]

Hi @flomickl,
that is a good point. We should harmonize this behavior.
The main question is how we will model the sensor data. Maybe we can also find an example for some sensors (e.g. humidity sensor, acceleration sensor, temperature sensor, ...).

For me it was mostly sufficient to have a single "domainProperty", but maybe there are cases where someone needs several of them.

We should also change the terminology to semantic types. We have already changed this in the user interface, but not yet in the model.

[tenthe]

Yes, we can create a ticket to harmonize the behavior of semantic types.

As for nested properties and lists, perhaps we should discuss if we should remove them and only use flat events in StreamPipes.
This would simplify both the implementation and the usage for users, since there are many exceptions with these structures.

I would not completely eliminate lists, but only support basic types within them.
For this solution, adapters could still read more complex events, but they need to convert them into a flat structure.

This is just a first idea, any other ideas and opinions?
Cheers,
Philipp

[bossenti]

I'm in favor of creating a dedicated discussion for focusing on flat event structures
Do we need need to come to a conclusion before we tackle the harmonization of the semantic types?

[tenthe]

No, I don't think so. This should be two independent topics.
+1 for opening a separate discussion

[bossenti]

I've added the discussion to our overview of strategic discussions (#908).
@tenthe, @flomickl would you mind to create an issue for the harmonization of the semantic types?
Once this is done, I would lock this conversation

[flomickl]

I created an issue from the harmonize discussion #1243