properties to link into Inspire RDF resources.

[semanticfire]

To increase the use of Inspire RDF resources as an authorative source we need to be able to link 'into' the inspire resources.

On address level there is a property from the ISA Core Location Vocabulary which enables you to link any resource to the ISA representation of a address.

Currently there is no property to link any resource to e.g. a Land Parcel, it would make sense to have a generic property and subproperties to link into specific INSPIRE Themes.

e.g. relatedToParcel this would allow e.g. a Real Estate Agent to link an online offer for a piece of land they have for sale to the official data about the parcel.
In turn this would increase the authority level of the Real Estate Agent, they refer to a authoritative data source

[cportele]

If such properties would be added, should a property be provided for each INSPIRE spatial object type or only for selected ones that are frequently linked to (cadastral parcels, buildings, addresses, administrative units, etc.)?

[semanticfire]

I think this issue is exactly to discuss that, I haven't looked indepth in all the topics and how applicable it would be, but I think that everything which is in the physical environment and is a inspire topic should be external referencable

[semanticfire]

How can we help to move this forward?

[semanticfire]

bump

[cportele]

Thanks @semanticfire. We will plan this/next week how to resolve/address the open issues and get back.

[michellutz]

@semanticfire Sorry for not commenting on this earlier. I'm a bit sceptical about the proposal to have pre-defined properties for all INSPIRE classes, mainly because I think objects can be related to INSPIRE objects through different properties, e.g. (some simplified examples) Authority --responsibleForMaintenanceOf--> Road, Address --roadIncludedInAddress--> Road, ... The main question is what we would like to express/achieve with specififc pre-defined properties. From your proposal, it seems to me that you would like to express authoritativeness of the data pointed to, i.e. some indication of the data quality (or trustworthiness). But I am not sure that pre-defined properties are the best way to do this. Ultimately, use of data will show whether they are good/useful/trustworthy.

In the Core Location vocab, we added the properties for hasLocation and hasAddress as a convenience property (for the most used properties) rather than to express some additional (meta)semantics.

So, to cut a long story short - where a class is representing a (complex) data type (e.g. an address or a location), we can include a convenience property. Contrary, where classes represent spatial-things (e.g. road, building, ...), we do not include such a property.

HTH, Michael

[semanticfire]

But I am not sure that pre-defined properties are the best way to do this. Ultimately, use of data will show whether they are good/useful/trustworthy.

If there is no way to link to your data then the use is hard to measure.
In our current use case we are looking for a way to link to addresses, buildings and parcels, the rationale behind this is that a lot of public registrations, e.g. company register, permit register and parcel ownership are related to one of these 3 INSPIRE themes but without predefined properties its rather ambigious how to link to them.

[cportele]

If there is no way to link to your data then the use is hard to measure.
In our current use case we are looking for a way to link to addresses, buildings and parcels, the rationale behind this is that a lot of public registrations, e.g. company register, permit register and parcel ownership are related to one of these 3 INSPIRE themes but without predefined properties its rather ambigious how to link to them.

Without pre-defined properties those that link to the INSPIRE objects would decide which property to use (select an existing one or create a new one). The question is, if INSPIRE would create pre-defined properties, would others use them or would they use other properties anyhow?

In the early days of GML, we also had pre-defined feature properties like gml:position, gml:centerOf etc. where the value was always a GML geometry. The idea was that those were used in features with geometry. However, they were almost never used by those creating feature data and they minted their own properties as part of their schema/vocabulary. So these properties were first deprecated and later removed again.

Do we have evidence that this will be different in the RDF world? Is this a pattern that is typically used by other vocabularies, too? For example, FOAF does not define a re-usable property that allows me to reference a foaf:Person, AFAIK. Or PROV-O does not seem to define a re-usable property that allows me to reference a prov:Entity.