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

Enter more precise geolocations. #17

Open
ahluntang opened this issue Jul 9, 2013 · 9 comments
Open

Enter more precise geolocations. #17

ahluntang opened this issue Jul 9, 2013 · 9 comments
Labels
Milestone

Comments

@ahluntang
Copy link
Member

This is partly the cause for issue #16

ahluntang added a commit that referenced this issue Jul 9, 2013
@ahluntang
Copy link
Member Author

Some events refer to a geolocation with multiple addresses:
Example on: https://datahub.westtoer.be/WIN/Events/location/51.0983650,2.5878850.about

@marc-portier
Copy link

@mielvds hebben we daar binnen datahub-mapping een logische verklaring voor?

@mielvds
Copy link

mielvds commented Jul 10, 2013

yes, the coördinates are used to create the URI. If multiple events use the same coördinates, but a different address, the distinct adresses get added. This is in fact not false, because the data says the address corresponds to these coördinates. In an RDF world, we can not say which is false, so everything is added.

@marc-portier
Copy link

hm,

maybe we should not promote the coordinates to having IDENTIFICATION power
(ie use them to assemble the URI)

-marc=

2013/7/10 mielvds [email protected]

yes, the coördinates are used to create the URI. If multiple events use
the same coördinates, but a different address, the distinct adresses get
added. This is in fact not false, because the data says the address
corresponds to these coördinates. In an RDF world, we can not say which is
false, so everything is added.


Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-20750759
.

@marc-portier
Copy link

To further argument:
These coordinates are often calculated/retrieved from some geoloxator
service, so they are not human controlled/verified...
/m
Op 10 jul. 2013 17:39 schreef "mielvds" [email protected] het
volgende:

yes, the coördinates are used to create the URI. If multiple events use
the same coördinates, but a different address, the distinct adresses get
added. This is in fact not false, because the data says the address
corresponds to these coördinates. In an RDF world, we can not say which is
false, so everything is added.


Reply to this email directly or view it on GitHubhttps://github.com//issues/17#issuecomment-20750759
.

@mielvds
Copy link

mielvds commented Jul 10, 2013

ok, what is consistent enough cross-dataset to use as id?

@marc-portier
Copy link

Since you ask, I assume there is no option to have some "anonymous" object...
I see only two options:
1/ use some aggregation of the address: city/street-number >> but I'm afraid some events might only have a "city"

2/ make an addres-subresource of the entity we're mapping, so Win/Events/21938/address
this will prevent to find multiple events on the same address, but that only shows the address info isn't normalized in the dataset

any other ideas / remarks?

-marc=

@mielvds
Copy link

mielvds commented Jul 11, 2013

0/
there is, it's called blank nodes, but it's definitely not a better solution than any of the other two you propose

1/ use some aggregation of the address: city/street-number >> but I'm afraid some events might only have a "city"

that's what we did at first, but as you mention, de presence of certain values caused inconsistencies and ugly uris

2/ make an addres-subresource of the entity we're mapping, so Win/Events/21938/address
this will prevent to find multiple events on the same address, but that only shows the address info isn't normalized in the dataset

something like this is of course possible. You could have a separate dataset holding all addresses, but this needs a real normalization process

@marc-portier
Copy link

ok, let's agree on the subresource approach then
the current dataset isn't suitable for the denormalization

I made an issue for this in datahub-config https://github.com/westtoer/datahub-config/issues/85

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants