Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

geo location metadata #961

Merged
merged 4 commits into from
Sep 21, 2020
Merged

geo location metadata #961

merged 4 commits into from
Sep 21, 2020

Conversation

sebastiankb
Copy link
Contributor

request from #941

@sebastiankb
Copy link
Contributor Author

from today's TD call:

  • @mmccool samples shall relevant to concrete use case
  • we shall discover the findings from the next PlugFest
  • proposal is to merge the PR for now and make them available for the next draft, however, examples will be modified based on the findings from PlugFest
  • there will be editorial note that points out the WIP status --> @sebastiankb
  • the second update shall be updated to a property that return location based data --> @sebastiankb

"@context": [
"https://www.w3.org/2019/wot/td/v1",
{
"wgs84": "http://www.w3.org/2003/01/geo/wgs84_pos#"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the usual prefix for WGS84 is geo (see prefix.cc)

Copy link
Contributor

@vcharpenay vcharpenay Sep 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but it might be confusing for readers to use two different vocabularies (WGS84 and schema.org) for the same kind of information (long/lat). WGS84 is very small and entirely included in schema.org (semantically). It might be better to use schema.org only.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will change this to geo.

It might be better to use schema.org only.

Thats right. The intention was to show different examples that uses different ontologies.

],
...
"properties": {
"status": {
Copy link
Contributor

@vcharpenay vcharpenay Sep 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the example intends to show how e.g. to interpret

{
  "long": 40.75,
  "lat": 73.98,
  "height": 15
}

as

{
  "@context": "http://schema.org/",
  "schema:longitude": 40.75,
  "schema:latitude": 73.98,
  "schema:elevation": 15
}

.

I provide an example for this in the JSON Schema in RDF vocabulary, which simply consists in linking to a JSON-LD context from the TD, as follows

{
  "properties": {
    "position": {
      "jsonld:context": {
        "schema": "http://schema.org/"
        "long": "schema:longitude",
        "lat": "schema:latitude",
        "height": "schema:elevation"
      },
      "type": "object",
      "properties": {
        "long": { "type": "number" },
        "lat": { "type": "number" },
        "height": { "type": "number" }
      }
    }
  }
}

The value for jsonld:context is an inline JSON-LD context that provides a mapping for long, lat and height.

Copy link
Contributor Author

@sebastiankb sebastiankb Sep 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be also possible to use this example?

{
  "properties": {
    "position": {
      "type": "object",
      "properties": {
        "@type" : "schema:GeoCoordinates",
        "longitude": { "type": "number" },
        "latitude": { "type": "number" },
        "elevation": { "type": "number" }
      }
    }
  }
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as a further example, yes. I would keep the one with jsonld:context, though, because it corresponds to another requirement.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets keep both approaches to show the different kind of options how semantic based annotations can be applied.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it be:

{
  "properties": {
    "position": {
      "type": "object",
       "@type" : "schema:GeoCoordinates",
      "properties": {
        "longitude": { "type": "number" },
        "latitude": { "type": "number" },
        "elevation": { "type": "number" }
      }
    }
  }
}

?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, my bad.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the hint. I updated the example.

@sebastiankb sebastiankb requested a review from mmccool September 17, 2020 10:41
@sebastiankb
Copy link
Contributor Author

I updated the samples based on @vcharpenay feedback.

@sebastiankb
Copy link
Contributor Author

merge this PR and apply the new render script as next

@sebastiankb sebastiankb merged commit 105ce01 into master Sep 21, 2020
@egekorkan egekorkan deleted the geo-location branch January 28, 2022 22:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants