Location-realted issues

OP-TED / ePO

The eProcurement Ontology provides the formal, semantic foundation for the creation and reuse of linked open data in the domain of public procurement in the EU.

European Union Public License 1.2

58 stars 18 forks source link

Location-realted issues #266

Closed paulakeen closed 1 year ago

paulakeen commented 3 years ago

We need to review where and how Location and Address are used. There seems to be a non-unique/harmonised way of treating locations and addresses.

muricna commented 3 years ago

After discussion the WG suggests to use the Core Location Vocabulary: 1.Location only when mentioning areas ie Country or country subentities

Address when mapping addresses so the attribute full address can be used

Therefore the model should be revisited so to reflect the core location Vocabulary in the classes Location and Address and their corresponding predicates which should include predicates to Organisation The WG also suggests to take into consideration the Geometry class from the Core Location Vocabulary which could be useful when addresses are not avialable ie the position of an Oil rig that is involved in procurement.

giorgialodi commented 3 years ago

In the revision of the Consip mapping I am realizing that the properties for LocationCoordinate (that is linked to Address) do not make a lot of sense modelled according to version 2.0.1. We have attributes that distinguish between degrees and minutes but their value is Measure that is composed by a decimal and a unit of measure (that can probably be degree or minute). And honestly I've never seen lat and long expressed in minutes in real data so far.

Don't you think we can simply this part also in version 2.0.1?

giorgialodi commented 3 years ago

Regarding this issue, last summer I tried to design in UML a possible schema for the location part of the epo ontology, stimulated by the BDTI pilot. It was a mix of Core Location Vocabulary and INSPIRE Address specifications. Here there is an example of possible Location modelling considering CLV and INSPIRE.

Just for the discussion :)

VladimirAlexiev commented 3 years ago

epo:Geometry: why not reuse GeoSPARQL for geometries? (asWKT, asGML and the corresponding datatypes). The above only covers point geometries, and furthermore in a completely non-standard way, so repositories with geospatial support won't index epo:Geometry
spelling mistake: situatted
epo:Identifier should be aligned with adms:Identifier
epo:Identifier mixes props of an individual identifier and an Identifier Scheme, please move the latter to their own class (we did that in euBusinessGraph).
merge Location and AddressComponent: why can't the former have a hierarchy, and the latter have geometries?
anyURI is a XSD datatype, not a prop name. If you want to use such prop, call it uri and use a real URL (object prop without range), not a literal

costezki commented 1 year ago

Location and Address usage are aligned to Core Location now.