European Commission logo
INSPIRE Community Forum

Managing Polymorphism and Duality

Keiran MILLARD
By Keiran MILLARD Replies (11)

I thought I had raised this topic before, but I can't find the thread.  Anyway, this topic is about what to do about datasets that can belong to more than one theme - or can change between themes overtime. 

This happens a lot in the marine / atmosphere group and I don't think we are unique.  An example may be a SR, but is also used for AM.  Now a community may agree 'we will model this as AM' - agreement, consensus.  But the dataset may be viewed by others as an SR - especailly during data searches. 

I think it would be useful to model this polymorphism in some way, i.e. to allow a dataset to be modelled one way, but also to make it explicit it could be modelled another way.  Dataset modlledAs [AM] releatedTo [SR].  In the EF specification there is the concepte of geneology and heirachy and I was thinking if this pattern was more far reaching than the EF specifcation.

  • Michael LUTZ

    Good question. I think currently the only way to do this would be to transform your data to the two (or more) separate data models. I think the models where such possible overlaps exist are relatively simple (e.g. SR and AM) and this should be doable without too much effort.

    However, I think we also should take good care in analysing whether there really is an overlap (we had quite a few discussions, as you will remember, to try and sort out overlaps during the DS development). Taking your SR-AM example, there is a difference between the two concepts. SRs are zones that are delineated based on physical/chemical/biological characteristics, while AMs are zones that are laid down in a legal act or regulation. The delineation of the AM may be based on the delineation of the SR, but it captures different attributes (the legal basis for the restriction etc.). In fact, this is already considered in the AM specification and should be documented in the lineage MD:

    IR Requirement (Annex IV, Section 11.4.1) - Theme-specific Requirements – Management Restriction Or Regulation Zones
    (2) If the geometries of the spatial objects in a ManagementRestrictionOrRegulationZone data set are derived from the geometries of spatial objects in another data set, then this source data set (including its version) shall be described as part of the lineage metadata element.

  • Keiran MILLARD

    By Keiran MILLARD

    There was a lot of effort at the drafting stage between SR and AM in particular to mitigate / embrace issues of duality.  This approach worked well and the IR Requirement is a good, practical outcome of the discussion.  I tend to use the AM:SR as an example with duality as I think its a good example - and I am also familiar with this!

    I am re-starting this discussion really in the context of the Marine Pilot and Emodnet where this topic seems to come up time and again and I think we should have a set of techniques we can use to support Inspire implementers.  So far we have

    (a) Explicit guidance in the documents how to management duality (where such duality was anticipated at the drafting stage).  This may not cover all situation, but could be used as an example to follow in other situations.  If it is very important than the documents can always be revised to include this.

    (b) Community Decision.  A community can decide which theme a dataset belongs to and promote this as 'best practice'.  This can work well if it is a well-supported community as others will follow. 

    (c) Multiple Instances.  A dataset is transformed to multiple Inspire data models representing the different viewpoints of what the data is.  In many cases this may not  be particulalrly onerous, however it may not be practical in all cases.  The metadata can be used to publicise what other instances of the data exist (like the SR:AM example in the IR).

    The main point for me is that we do not know how significant an issue duality is for all cases.  At the drafting phase we recognised the importance of this an made signficant steps to embrace it (notably all the work on standard O&M patterns).  We can however only fully understand this from practical examples such as Emodnet and the Marine Pilot and thats why I think such pilots are important.  In doing so, we should consider solutions that can be applied.

  • Michael LUTZ

    You are right that best practices for these kinds of questions would be useful. Probably we should start with collecting some real examples to illustrate the problem and possible solutions.

    [On a side note: I have recently been looking at the OSM data model that basically only has three data types: points, lines and relationships. All other information, including types are managed through tags. Such a simple data model would make "reuse" of an spatial object (basically just the geometry) for different purposes much easier - you would simply add a tag saying that your SR now also is an AM...]

  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    I agree. I find this discussion important too. Some recommendation or guidelines would be great to have on this issue.

    Most LC and LU datasets are actually a mixture of both LC and LU, and splitting them in two is not optimal for the sake of harmonization. The data models are also quite different as it is now. Perhaps something could be done here to synchronize the contents of the data models.

    For example the Land Parcel Identification System (LPIS) and related IACS data has been reported differently from country to country. Some countries find that it is LC and others that its LU and both are correct. It depends on which attributes you decide to attach to your spatial objects.

    The idea to be able to put a tag from another team sounds also interesting from LC and LU point of view...

    Lena

     

     

  • Keiran MILLARD

    By Keiran MILLARD

    Hi Lena,

    You say:

    For example the Land Parcel Identification System (LPIS) and related IACS data has been reported differently from country to country. Some countries find that it is LC and others that its LU and both are correct. It depends on which attributes you decide to attach to your spatial objects.

    I think this comment goes right to the issue.  No matter what guidance is given there will be cases like this that cannot be resolved as 'both are correct' as you say.  In the longer term we may look to improve the data models to make them distinct, but this is not for now!

    Two comments, the first is related to Micheal's comment on OSM.  If the use case is simply plotting on a map (the OSM use case)  then provided the LU/LC dataset (or the AM/SR dataset) has the same geometry then this is easy.  What could not be satisfied are use cases that made use of more detailed attributes.

    When we looked at MarineXML (many years ago).  We considered the concept of 'processing affordance' to help consider what we meant by interoperability.  This means 'what can I do with with this data?' .We also looked at 'sensible plotting' as a test.  This means software should be able to portray the data sensible without human intervention.  So 'plot on map' may be one example, or 'plot as a graph' (with O&M data).  I think we can satisfy the sensible plotting test in Inspire whether it is called LC or LU or SR or AM and some tagging to relate them would support searches / services, e.g. It is not often we want data that is 'exactly LC' but 'all data in this area that is about what happens on land (or sea)'.

     

     

  • Keiran MILLARD

    By Keiran MILLARD

    Just an addition to this debate that I picked up from the Inspire Marine Pilot project.  This project has an example of duality between EF and OF.  In Inspire, O&M coverage types are detailed in the Inspire GCM and used identially by EF, OF, and AF.   This is good for interoperability, however it gives the publisher freedom (=confusion in some cases!) over which theme to publish a dataset under which may not help discovery and may limit certain services is they are only bound to one theme.  In most cases (considering the processing affordance concept), I would like it to be explicit that for many use cases I can treat an OF and EF dataset in a similar way for services such as 'plot a graph'.  There is a similar discussion here:

    https://themes.jrc.ec.europa.eu/discussion/view/35152/ef-om-and-results-data-in-other-themes

     

     

  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Could we talk about this 'Managing Polymorphism and Duality' topic during out TeleCon on Wednesday, to discuss and agree upon how to proceed with this issue, if we do.

    It would be good if we could give support on which dataset belongs to which theme. However, it's also a matter of policy. If it is not of top priority (as I have understood it isn't for now), it may not be anything we can or should do something about.

  • Keiran MILLARD

    By Keiran MILLARD

    Hi Lena,

    Re:' Could we talk about this 'Managing Polymorphism and Duality' topic during out TeleCon on Wednesday,'

    Is there a teleconference on Weds? I do not have and details :-(

    Keiran

  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Hi Keiran,

    I meant the TeleCon between the Facilitators and JRC on Wednesday 10-12 CET. Invitation for it was sent out by Robert last week and he asked for topics, so this is my suggestion :). I hope you agree.

    Lena

     

  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Hi,

    FYI: There's a question related to this Duality etc. issue in LCLU cluster:

    https://themes.jrc.ec.europa.eu/discussion/view/43283/land-cover-coverage-and-data-duplication

    Luckily I don't have to give an answer ;)

    @ Anja: How did you reason about this in ELF, where you also deal with LC, TN etc.? Any hint who I could encourage to give an answer on the approach in ELF?

    @ JRC?

    Lena

This discussion is closed.

This discussion is closed and is not accepting new comments.

Facilitators group

Facilitators group

A cross thematic cluster resource