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

Improve handling of geospatial terms in CTDL #460

Closed
siuc-nate opened this Issue Sep 11, 2017 · 8 comments

Comments

@siuc-nate

siuc-nate commented Sep 11, 2017

A week or two ago, @stuartasutton mentioned wanting to review the geospatial classes and properties in CTDL to see if we could make improvements. Currently we have a variety of them, which were added at varying points in development, and they are somewhat difficult to explain and harmonize:

Classes:

Properties:

Concept Schemes / Concepts:

Notes:

  • Some of these relate to the groups of properties that define relationships (e.g., ___By, ___In, ___s, ___Service) - perhaps these groups should be reviewed for optimization as well
  • The ContactPoint class's other properties may be tangentially related
  • This will likely also influence a proposal discussed internally to enable issuing a CTID to a campus/address (effectively either a mini-organization or an expansion of PostalAddress) so it can be referenced
    • This may also influence the use of subOrganization, department, and parentOrganization, since those would currently be the "right" way to handle campus locations
  • According to the definition of spatialCoverage, many of these properties should also be subproperties of spatialCoverage

Summary:
@stuartasutton is quite right - these could do with a lot of cleaning up. Geospatial terms seem to mostly fall into one of two buckets: Terms to indicate an area (e.g., JurisdictionProfile) and terms to indicate a specific place (e.g., PostalAddress). However, this is complicated by the interplay of an area and things that happen in that area (e.g. the relationship properties) as well as cases where address and other information have a many-to-many relationship (e.g., socialMedia, telephone, etc., applying to 0-n locations vs being organization-wide).

We will have to be very mindful of the ripple effects of any changes we make here.

@siuc-nate

This comment has been minimized.

Show comment
Hide comment
@siuc-nate

siuc-nate Sep 22, 2017

One proposal that @cwd-mparsons and I discussed would be to create a new class (something like ceterms:Place) that would essentially combine the properties of both PostalAddress and GeoCoordinates (and possibly ContactPoint). This would grant the added utility of being able to directly associate a latitude and longitude with an address in addition to simplifying the location-related information tied to contact point, on top of solving the "campus" issue mentioned in the post above. The replaced classes would subsequently be deprecated and superseded by this new class.

siuc-nate commented Sep 22, 2017

One proposal that @cwd-mparsons and I discussed would be to create a new class (something like ceterms:Place) that would essentially combine the properties of both PostalAddress and GeoCoordinates (and possibly ContactPoint). This would grant the added utility of being able to directly associate a latitude and longitude with an address in addition to simplifying the location-related information tied to contact point, on top of solving the "campus" issue mentioned in the post above. The replaced classes would subsequently be deprecated and superseded by this new class.

@siuc-nate

This comment has been minimized.

Show comment
Hide comment
@siuc-nate

siuc-nate Sep 22, 2017

Proposal:

  1. Create a new class and merge ceterms:GeoCoordinates and ceterms:PostalAddress into it:

URI: ceterms:Place
Label: Place
Definition: A location or area.
Properties:

  • ceterms:name
  • ceterms:description
  • ceterms:geoURI
  • ceterms:latitude
  • ceterms:longitude
  • ceterms:streetAddress
  • ceterms:addressLocality
  • ceterms:addressRegion
  • ceterms:addressCountry
  • ceterms:postalCode
  • ceterms:postOfficeBoxNumber
  • ceterms:targetContactPoint
  1. Update the range of all properties that currently point to either ceterms:GeoCoordinates or ceterms:PostalAddress to instead point to ceterms:Place

  2. Deprecate (or just destabilize) ceterms:GeoCoordinates and ceterms:PostalAddress

  3. Remove ceterms:CredentialOrganization and ceterms:QACredentialOrganization from the domain of ceterms:targetContactPoint

siuc-nate commented Sep 22, 2017

Proposal:

  1. Create a new class and merge ceterms:GeoCoordinates and ceterms:PostalAddress into it:

URI: ceterms:Place
Label: Place
Definition: A location or area.
Properties:

  • ceterms:name
  • ceterms:description
  • ceterms:geoURI
  • ceterms:latitude
  • ceterms:longitude
  • ceterms:streetAddress
  • ceterms:addressLocality
  • ceterms:addressRegion
  • ceterms:addressCountry
  • ceterms:postalCode
  • ceterms:postOfficeBoxNumber
  • ceterms:targetContactPoint
  1. Update the range of all properties that currently point to either ceterms:GeoCoordinates or ceterms:PostalAddress to instead point to ceterms:Place

  2. Deprecate (or just destabilize) ceterms:GeoCoordinates and ceterms:PostalAddress

  3. Remove ceterms:CredentialOrganization and ceterms:QACredentialOrganization from the domain of ceterms:targetContactPoint

@stuartasutton

This comment has been minimized.

Show comment
Hide comment
@stuartasutton

stuartasutton Sep 23, 2017

Contributor

While accepting the changes noted above in terms of the creation of a new ceterms:Place class and the consolidation of terms from ceterms:GeoCoordinates and PostalAddress for both general use and as controlling in the Registry, I think we should not follow through with note no. 3 (i.e., deprecating). Instead, while adding ceterms:Location, pare down the acceptable properties of GeoCoordinates and PostalAddress in the CTDL thus:

GeoCoordinates

ceterms:geoURI
ceterms:latitude
ceterms:longitude
ceterms:name

PostalAddress

ceterms:addressCountry
ceterms:addressLocality
ceterms:addressRegion
ceterms:name
ceterms:postalCode
ceterms:postOfficeBoxNumber
ceterms:streetAddress

That would entail the properties having two domains, but that is not a problem in either RDF or schema.org.

Accepting the new ceterms:Location class should not be contingent on consideration of not deprecating.

Contributor

stuartasutton commented Sep 23, 2017

While accepting the changes noted above in terms of the creation of a new ceterms:Place class and the consolidation of terms from ceterms:GeoCoordinates and PostalAddress for both general use and as controlling in the Registry, I think we should not follow through with note no. 3 (i.e., deprecating). Instead, while adding ceterms:Location, pare down the acceptable properties of GeoCoordinates and PostalAddress in the CTDL thus:

GeoCoordinates

ceterms:geoURI
ceterms:latitude
ceterms:longitude
ceterms:name

PostalAddress

ceterms:addressCountry
ceterms:addressLocality
ceterms:addressRegion
ceterms:name
ceterms:postalCode
ceterms:postOfficeBoxNumber
ceterms:streetAddress

That would entail the properties having two domains, but that is not a problem in either RDF or schema.org.

Accepting the new ceterms:Location class should not be contingent on consideration of not deprecating.

@siuc-nate

This comment has been minimized.

Show comment
Hide comment
@siuc-nate

siuc-nate Sep 25, 2017

The proposal to do something about GeoCoordinates and PostalAddress is partly in hopes of making CTDL easier to understand for newer developers - having those in addition to a Location class may actually make things worse. However, I do see the potential usefulness of them (or at least, of address) at some point, so maybe deprecating is too harsh. Would it suffice to remove them from the range of any properties that currently point to them (Item 2 in my post above) so as to disconnect them from real interaction with other parts of CTDL?

siuc-nate commented Sep 25, 2017

The proposal to do something about GeoCoordinates and PostalAddress is partly in hopes of making CTDL easier to understand for newer developers - having those in addition to a Location class may actually make things worse. However, I do see the potential usefulness of them (or at least, of address) at some point, so maybe deprecating is too harsh. Would it suffice to remove them from the range of any properties that currently point to them (Item 2 in my post above) so as to disconnect them from real interaction with other parts of CTDL?

@stuartasutton

This comment has been minimized.

Show comment
Hide comment
@stuartasutton

stuartasutton Sep 25, 2017

Contributor

Yes, removal from range would have that affect.

Contributor

stuartasutton commented Sep 25, 2017

Yes, removal from range would have that affect.

@siuc-nate siuc-nate added the Pending label Sep 26, 2017

@stuartasutton

This comment has been minimized.

Show comment
Hide comment
@stuartasutton

stuartasutton Sep 29, 2017

Contributor

Where do we stand on this issue around our locational classes. We are in agreement with your comment above, Nate, to consolidate properties from GeoCoordinates and PostalAddress. But what have we decided about my comment above about not deprecating GeoCoordinates and PostalAddress but paring down the properties to make each very precise?

Contributor

stuartasutton commented Sep 29, 2017

Where do we stand on this issue around our locational classes. We are in agreement with your comment above, Nate, to consolidate properties from GeoCoordinates and PostalAddress. But what have we decided about my comment above about not deprecating GeoCoordinates and PostalAddress but paring down the properties to make each very precise?

@siuc-nate

This comment has been minimized.

Show comment
Hide comment
@siuc-nate

siuc-nate Oct 20, 2017

Actions to be taken:

Create
URI: ceterms:Place
Label: Place
Definition: Entity describing a physical location or geospatial area.
Properties:

  • ceterms:name
  • ceterms:description
  • ceterms:geoURI
  • ceterms:latitude
  • ceterms:longitude
  • ceterms:streetAddress
  • ceterms:addressLocality
  • ceterms:addressRegion
  • ceterms:addressCountry
  • ceterms:postalCode
  • ceterms:postOfficeBoxNumber
  • ceterms:targetContactPoint

Remove ceterms:GeoCoordinates from the rdfs:domainIncludes of these properties:

  • ceterms:address
  • ceterms:url (this was deprecated but never removed)

Remove ceterms:GeoCoordinates from the rdfs:rangeIncludes of these properties:

  • ceterms:availableAt
  • ceterms:jurisdictionException
  • ceterms:mainJurisdiction
  • ceterms:region

Remove ceterms:PostalAddress from the rdfs:rangeIncludes of these properties:

  • ceterms:address
  • ceterms:availableAt

Add ceterms:Place to the rdfs:rangeIncludes of these properties (all of the properties that no longer point to GeoCoordinates or PostalAddress, except for spatialCoverage):

  • ceterms:address
  • ceterms:availableAt
  • ceterms:jurisdictionException
  • ceterms:mainJurisdiction
  • ceterms:region

Remove the following from the rdfs:domainIncludes of ceterms:targetContactPoint (its only domain will be ceterms:Place and ceterms:CredentialPerson):

  • ceterms:CredentialOrganization
  • ceterms:QACredentialOrganization
  • ceterms:PostalAddress

Add the following to the rdfs:rangeIncludes of ceterms:spatialCoverage:

  • ceterms:PostalAddress
  • ceterms:Place

The end result of these changes should be:

  • The creation of ceterms:Place as described above
  • ceterms:GeoCoordinates and ceterms:PostalAddress having the properties described in #460 (comment)
  • No properties (except spatialCoverage) having an rdfs:rangeIncludes of GeoCoordinates or PostalAddress
  • All properties that used to point to GeoCoordinates or PostalAddress now point to Place
  • Significantly more sanity in our handling of geospatial data
  • ceterms:spatialCoverage having a range of geospatial classes

siuc-nate commented Oct 20, 2017

Actions to be taken:

Create
URI: ceterms:Place
Label: Place
Definition: Entity describing a physical location or geospatial area.
Properties:

  • ceterms:name
  • ceterms:description
  • ceterms:geoURI
  • ceterms:latitude
  • ceterms:longitude
  • ceterms:streetAddress
  • ceterms:addressLocality
  • ceterms:addressRegion
  • ceterms:addressCountry
  • ceterms:postalCode
  • ceterms:postOfficeBoxNumber
  • ceterms:targetContactPoint

Remove ceterms:GeoCoordinates from the rdfs:domainIncludes of these properties:

  • ceterms:address
  • ceterms:url (this was deprecated but never removed)

Remove ceterms:GeoCoordinates from the rdfs:rangeIncludes of these properties:

  • ceterms:availableAt
  • ceterms:jurisdictionException
  • ceterms:mainJurisdiction
  • ceterms:region

Remove ceterms:PostalAddress from the rdfs:rangeIncludes of these properties:

  • ceterms:address
  • ceterms:availableAt

Add ceterms:Place to the rdfs:rangeIncludes of these properties (all of the properties that no longer point to GeoCoordinates or PostalAddress, except for spatialCoverage):

  • ceterms:address
  • ceterms:availableAt
  • ceterms:jurisdictionException
  • ceterms:mainJurisdiction
  • ceterms:region

Remove the following from the rdfs:domainIncludes of ceterms:targetContactPoint (its only domain will be ceterms:Place and ceterms:CredentialPerson):

  • ceterms:CredentialOrganization
  • ceterms:QACredentialOrganization
  • ceterms:PostalAddress

Add the following to the rdfs:rangeIncludes of ceterms:spatialCoverage:

  • ceterms:PostalAddress
  • ceterms:Place

The end result of these changes should be:

  • The creation of ceterms:Place as described above
  • ceterms:GeoCoordinates and ceterms:PostalAddress having the properties described in #460 (comment)
  • No properties (except spatialCoverage) having an rdfs:rangeIncludes of GeoCoordinates or PostalAddress
  • All properties that used to point to GeoCoordinates or PostalAddress now point to Place
  • Significantly more sanity in our handling of geospatial data
  • ceterms:spatialCoverage having a range of geospatial classes
@siuc-nate

This comment has been minimized.

Show comment
Hide comment
@siuc-nate

siuc-nate Oct 20, 2017

These changes have been made in the schema and marked in the history tracking.

siuc-nate commented Oct 20, 2017

These changes have been made in the schema and marked in the history tracking.

@siuc-nate siuc-nate closed this Oct 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment