Geo enabling your APIs with the location building blocks
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 266 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/66407 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
CollaborationismPresentation of a groupStandard deviationBitComputer programmingCentralizer and normalizerElectric generatorSoftware developerArithmetic progressionComputer animation
01:23
View (database)Standard deviationService (economics)SoftwareEndliche ModelltheorieMereologyTerm (mathematics)Process (computing)Integrated development environmentTemplate (C++)Numbering schemeTerm (mathematics)Level (video gaming)Lattice (order)Different (Kate Ryan album)Library catalogStandard deviationSoftwareState observerAreaNP-hardDomain nameImplementationDivisorFilm editingAbelsche ErweiterungRepresentation (politics)Endliche ModelltheorieMultiplicationMeasurementOffice suiteExtension (kinesiology)Connectivity (graph theory)Arithmetic meanRevision controlOpen sourceProduct (business)WhiteboardComputer animation
04:49
Parameter (computer programming)Standard deviationConformal mapData structureElement (mathematics)ImplementationMereologySocial classComputer animation
05:20
Database transactionQuery languageSample (statistics)MereologyLink (knot theory)QuicksortLattice (order)Descriptive statisticsImplementationMereologyEndliche ModelltheorieRaster graphicsQuery languageKey (cryptography)Web 2.0Arithmetic meanTesselationCategory of beingRepresentation (politics)Set (mathematics)Self-organizationVector spaceStandard deviationWeb pageSummierbarkeitRoboticsCondition numberSeries (mathematics)Parameter (computer programming)Computer animation
07:59
Parameter (computer programming)ImplementationAreaBoundary value problemMereologyStatistical dispersionElectric generatorCuboidOrder (biology)
08:40
Digital filterTablet computerWeb pageSample (statistics)Local GroupCodeContinuous functionFamilySuite (music)CuboidRepresentation (politics)Element (mathematics)Web pageStandard deviationUniform resource locatorComputer animation
09:33
PermianParameter (computer programming)Point (geometry)Open sourceLink (knot theory)AbstractionLocal GroupWaveSoftware testingComputer-generated imageryFile formatMereologyNumbering schemeObject (grammar)Maxima and minimaBitConnectivity (graph theory)Standard deviationDescriptive statisticsCuboidElement (mathematics)Interface (computing)Keyboard shortcutLevel (video gaming)Service (economics)Software testingValidity (statistics)Mechanism designMereologyIdentifiabilityInternet der DingeImplementationDifferent (Kate Ryan album)Public key certificateLinked dataIntegrated development environmentSoftwareUniformer RaumData modelDiagramProgram flowchartComputer animation
11:57
Revision controlOrientation (vector space)RotationAngleMaxima and minimaNumbering schemeStandard deviationPosition operatorElement (mathematics)SpacetimeObject (grammar)Orientation (vector space)Uniform resource locatorVideoconferencingArithmetic meanRotationNamespaceExtension (kinesiology)SphereComputer wormComputer animation
13:49
Numbering schemeRevision controlMaxima and minimaContext awarenessArithmetic meanCondition numberElement (mathematics)Computer animation
14:09
Uniform resource locatorRotationAngleRevision controlNumbering schemeMaxima and minimaSemantics (computer science)Point (geometry)Validity (statistics)Computer animation
14:37
Meeting/InterviewLecture/Conference
17:08
Standard deviationSemantics (computer science)ConsistencySoftware testingRootOpen sourceMereologyExtension (kinesiology)Arithmetic meanElement (mathematics)Standard deviationWeb pageComputer wormOpen setAuthorizationImplementationDynamical systemKey (cryptography)Latent heatMenu (computing)Address spaceSoftwareComputer animation
18:36
Standard deviationWeb pageWebsiteElement (mathematics)Computer animation
18:54
Standard deviationGroup actionImplementationOpen setInternet forumTime domainWebsiteCore dumpStandard deviationGroup actionTestbedMereologyLatent heatSoftware developerRevision controlSoftware testingImplementationProjective planeValidity (statistics)Extension (kinesiology)Process (computing)Open sourceCASE <Informatik>Staff (military)FeedbackMusical ensembleDifferent (Kate Ryan album)Integrated development environmentEvent horizonComputer filePlastikkarteInstance (computer science)TelecommunicationComputer animation
Transcript: English(auto-generated)
00:08
We are just wondering, maybe, who of you is working in any standardization activities?
00:22
Okay, there's one non-person, two, okay. And who is aware of standards that you are using? Okay, that's a little better. So, yeah, we are looking for the next generation of the standards and how they will be defined,
00:43
how can we contribute, what are the actual struggles when we are defining those standards. I'm from the Collaborative Solutioning Innovation Program, leading these initiatives, mostly in Europe as a colleague, and closely cooperating with the standardization program
01:01
and also with this development relationship team. The presentation is actually a contribution from the Jonas and Simone, and Robert Kinsell, Andrew, Ilara, and a little bit from myself, and I will show you what are the ideas and what are the, let's say, progress in that building blocks.
01:25
Can the production of, why do we work on that? First of all, we are working in different domains, that's mostly geospatial information, but that's already used in multiple sectors, and it's not only every sector,
01:44
but every, maybe, agency, maybe some countries who like to define their, they have their own needs in terms of using the standards. So there are ideas, okay, let's extend the standards, and actually you can do that, there's this application extension that you can use, and then you want to use it on the open source software,
02:03
there's a board because it's just not supported, and you don't even know how to compare that. So if you have two extensions, this is really hard work, and boring actually, to go through all of those dependencies and try to map these different pieces together, how to represent it on the technical level, on the bidding level, and how to reduce that.
02:27
So, on one hand we say we need to reduce the cost, also bring this additional value so we can reach out more customers, to more communities with the standards, so that's like a scaling factor.
02:44
So we define those requirements. Then, they have different aspects, and so usually they, as we recognize, they are over-specified in some of the areas, under-specified in the other areas, so we need those kind of extensions.
03:02
And then we have these different aspects of the interoperability, so there is an API that allows you to harmonize what is the behavior of different components that are using the standards, so if I'm querying the data, I'm discovering, I'm accessing the data, that's, let's say, behavior, yeah?
03:21
Then you have the schemas that are somehow related with the models. So the models is what we understand the meaning of the data. You have different representation of the data, and the models, of course, you have different understanding of the data, and so you can use, so we'll know, observation, for example, representation,
03:41
like who had the ISOGC observation measurements, that's already specified somehow, but naturally, that's not the only one that is used. Take the catalogs, you have now, I don't know how many standards for the catalogs, we were just talking like now, okay, I just learned that there's a new DCAT API,
04:02
which is a version of the geodecat. With geodecat, it's still not standard, actually, but there are other efforts to define, because, actually, everybody has their own idea of how it should be built. So I will go through several of these considerations, and how do we envision of these building blocks.
04:24
Building blocks naturally is also something that has different meanings. So let's stick to the idea that the building blocks is the, let's say, granular component that can be reused in different implementations. Can be software, can be schema, can be data, can be software, can be API. The first API can be a complete,
04:41
all of that stuff can be a building block. But it shall be somehow simple, then you can have aggregates of that, but that's, let's go not far. So, are you familiar with the OPC APIs in general? So yeah, some of you are. So if you're familiar with the standards,
05:02
you know that the standards have structure, and they have the conformance classes, or requirements classes, so set of requirements, then you have requirements. That's already kind of structured building blocks of the elements. And then you have the standards, in the standards you can implement sparkle blocks.
05:20
So take the very simple API features, which is the geospatial vector representation exchange, and yeah, that's already here for parts. So you can implement only one of them, and then you can implement as you wish, actually. Actually, you have to implement the first part, which is core, that's structurally
05:41
the organization of the data, and key properties of your data. And then if you want to use different CRSs, then you extend it with these CRS parts. If you want to have more fancy filtering, not based on the query parameters, you actually implement the SQL.
06:00
And then if you want to modify the data, so crude means create, replace, read, update, delete, yeah? So if you want to use these functionalities, that's not usually required, actually. You can do that and sort of say that this is implemented.
06:24
And what's good is that the standards implementation, so they need to declare what they are implementing. So if you open the standard page, or if your role is accessing the web page, which is implementing the standards, the API, you will know which parts are implemented in general,
06:43
because they can vary on the implementation of the requirements. And let's go farther. So we have the part that's now extracted as the API almost. The common part are all this first attempt to define these building blocks that will be reused all
07:02
along the other standards. That's inherited from the features, and that was extracted to the other standards. And then, again, you can extend. So based on the same common, you can have vector representation, but you can also have tiles. You can have EDR. And EDR also can inherit the features, actually.
07:24
That can be reflected. OK, what does it mean? So we have the web page, and that's exposing different data. So that's the example. You have this access to the data. That's just part one. But you have these tiles implementations already
07:42
of the same set of the data. It's in here, so we have the rasters. You can implement your styles, and you have also this common part, which is the description of the API, actually, in this meeting. So you have the common part that has the common model of the API description.
08:01
But then we go farther, and kind of a good example of the building blocks as we perceive that is the bounding box, because everybody is using bounding blocks if you want to narrow down to your area of interest. And on one hand, that's common, and that's well represented in the implementation, so on.
08:24
Then if you use the bounding box, you may know that even the order of the coordinates can be whatever you want. But this can be the ideal example of the bounding box. That's what we started with the next generation of the bounding box definition.
08:42
So in the definition, we mean that we have exactly documentation of this element. It has this HTML nice representation, so you can aggregate these different examples of how can we use that. That's also maybe for you, maybe for the people who are willing to implement
09:02
their own standard, because we know that there are also plenty of the standards that are not OGC. And GSI is quite popular in Europe now. So they also have the location. The location is actually something that they define and don't even reference to what that means. And the same with feature of interest.
09:20
What does it mean, feature of interest in GSL&D? It's something that you can find somewhere in the documentation, maybe, on page something, 115. And if you miss that, you don't really understand what's behind the data. So we have the standard of publication, these kind of components.
09:41
That's ISO. That's a little bit more too complicated. So we are now working on the register of these building blocks. That's quite simplified. It follows this 135 standard of the publication of the elements. But that's simplified. So we have just these three entities. We have the item.
10:01
It defines what does it mean, this value box. We have the relationship. We have the status, because some of them can be proposed, and some of this can be already major. And then we can actually have the implementation examples. We are following the best practices of linked data, which means each of these building blocks
10:20
is naturally somehow identify an entity itself. So if you are referring that your data element is the bounding box on your data model, you can refer strictly to the URI, which is Unifier Resource Identifier. And that's the animated definition of that element.
10:41
And actually, we have different needs on that description. So we have the human readable description, like the markdown. We have the JSON structure, the schema, all that element. We have the examples, because people need examples
11:03
how do they actually work. And not everybody is capable of willing to read the documentation. If there is an example, that's quite a common shortcut. And then there is the schema. And I will come back to the schema, because that's a very important part of the topic.
11:21
Then we have also the assets and the tests. So we have now the DHC society environment, which is providing you the validation mechanism. So if you are implementing your services or exposing your software, you can surround the side theme engine from OGC. And that will check if your interface is compliant
11:43
with the standards on some level. You can then apply for this situation, if you remember also, you can do it online. And that's the example of the more complicated, but not so much building blocks. So there is a standard that tries to define the position
12:03
of the element in the space. So take the drone. The drone is flying an object. So it has the location, but it has also the pitch. It has this orientation elements that can be expressed in this sphere. Does this work?
12:21
Not yet.
12:42
So you have this example of the element of the geocalls simple definition. So what I've mainly defined, the longitude, latitude, height, and then the rotation, which is somehow also defined in the standard. But then those things shall have the meaning.
13:08
So what does it mean? The longitude is not specified here, not yet. So the idea is that some of you may know that there is this JSON extension, which is a JSON-LD. JSON-LD is kind of naming space.
13:23
So you can define what are the meaning of those elements. Like, the longitude is coming from some of these definitions. So here we have namespace geocalls. And if we will use that last instead of latitude, then we know that it's coming from the geopalls definition
13:42
of those. And then I also annotated the payload. So that's not only for the definition of the API. That's for the definition of the data. So if we provide the context definition together
14:00
with the data, we already know what are the meanings of these different elements. And if we have longitudes from geopalls and the features and the EDR, if they would have one common reference point, then it will be just simple to understand what does it mean. And the schema is also important,
14:22
because the schema can be used for the validation. So if you have your APIs that defines what building blocks it's using, then you have referred to the schema. And then you can easily run the validation of your API. And as the validation is in the morning,
17:09
that actually sometimes we have the payload. And if we want to make it really reusable, we need to add this meaning to the data. And that's usually not coming from the open source, because the open source is generic.
17:22
And we are domain-specific. So if we want to add this meaning to the data, we usually semantically uplift the data. And that's really its part and the key elements and the key value of this semantic enrichment that needs to have this building blocks definition. So I will not go through the pipeline. Just to mention that there's an OGC called
17:44
dynamic authority that's accepting all the elements in the standards. And that's also committed to support its building blocks. So actually, if you are defining your own extension of the D-cap, or your own extension of the features, first, look into the building blocks, because maybe there's something that was already defined.
18:02
Maybe this works to reuse that. Then, if that's not, if you think that's useful, especially if you have the implementation, push that. You can open the issue of the D-cap and propose that, so others will reuse that, and others will actually use the same definition, so you will not get troubles
18:20
when you go to the implementation. And especially if you are using the software, then you will just keep the gap of this reiterating on the understanding of the data. So there's a GitHub. There's an open issue page. You have also the website, which is the building blocks,
18:42
blocksogc.org, and then the idea is not only to define the building blocks, but ideally to guide people what kind of standards should they use for their needs and what kind of elements can be used for that. So that's, that is all.
19:02
Okay, so thank you, Piotr, for the great introduction. Yeah, no questions. Yes, thank you. I guess there are questions, and so are there any questions to Piotr about building blocks? So I'm curious about where you promote this approach.
19:21
You go to this event, like Phosphogy, and you promote them on other sites as well? Yeah, now we have promoted it along these weeks, those working groups, which was successful because they contributed to the work. So they always... And we are just, you know, the business staff.
19:40
We are just facilitating this kind of work. The knowledge is always coming from the community, like this one, the OTC community, that really have this knowledge about these different cases. And, yeah, we need to promote it in this kind of open source community. One of the ideas is value makers,
20:01
so maybe that's a value in itself. We have experience in the project that we support, directly the implementation, but this kind of value makers could be useful. So if you are defining your own features for the current environment, and you have like 20 pilots that have their own definition for the things,
20:23
we are trying to align that and to try to use these building blocks in these kind of approaches. That's now also the exercise, that's true, but also the recent requests actually to OTC is that standards come with the validation.
20:41
So there are... Not all of the standards are actually given with the site environment, so you cannot run all of the tests against your validation. And this should help. I mean, this is an effort because you need to build that. If everybody has their own schema, that's just repeatable effort.
21:01
You need to review that again and again and again. If you have these building blocks, that's just easier. So definitely the working groups and the implementations. We also run these pilots, so that's open. The OTC test beds and pilots are pretty much open.
21:20
If you sign up, if you are selected, then you can take part in this kind of exercise to prove that you are completely open. That's one thing. And maybe another question to the audience. If there are developers around, are you interested in this approach or do you think it's valuable? Maybe some feedback from you.
21:40
I see someone saying yes. Yeah, that needs to think through and listen to feedback like offline also. One thing I was wondering about, because you were talking about extending DCAT with your own needs, but what we've been experiencing is that regional governments,
22:04
they are trying to narrow down the standards. For instance, we now have to follow something called DCAT APNO, which is like the Norwegian version and is probably a Swedish version as well. Yeah, I guess so. I would say that's the overall specification of the standard.
22:22
So if we could have identified this core and these extensions based on your experience and the other experience, then we can say, okay, this is the building blocks of the core of DCAT and these are the extensions. And then in the API, we can just say, okay, I'm using this and this and this and this,
22:41
and that's already useful. Yeah, so it looks like community is important to get involved. Yeah, community is also important. What you see is the community base. We are not a member of the community. Thanks for all that stuff involved in that activity. So that's thanks to the community that you have with us.
23:03
That's really interesting. Who's the CEO of Spatial? Okay, so I want to thank you again for the nice talk. Good job.