Add subjectWebpage to Place

[jeannekitchens]

Many educational institutions and other types of organizations can have departments and campuses, or suborganizations. Houston Community College among them https://credentialfinder.org/organization/4665/.

The request is to support a use case for putting subjectWebpage in range of

1. address https://credreg.net/ctdl/terms/address
2. availableAt https://credreg.net/ctdl/terms/availableAt

[siuc-nate]

The request is to support a use case for putting subjectWebpage in range of [...]

I think you mean: The proposal is to add ceterms:Place to the domain of ceterms:subjectWebpage.

Some background: The current use case involves a college that has a number of departments and, separately (in terms of how the data provider organize its data), a number of physical locations. It is the data provider's perception that every (or nearly every) one of the departments exists at every (or nearly every) physical location.

The twist is that the data provider maintains webpages for each location rather than (or perhaps in addition to) each department, and the provider wishes to publish links to these webpages.

There are a few different ways to tackle this. Some options:

Option one: Add ceterms:subjectWebpage to ceterms:Place

Good:

• It solves the problem for this and other places where a Place has an associated webpage
• It does not preclude adding CTID later on if we ever decide to do that (and in fact would still need to be done anyway if we did)
• No other (obvious) side effects

Bad:

• You still have to repeat the data (but this is how it is today already)

Ugly:

• It may open the door to expanding the Place class beyond its intended purpose (though it shouldn't be an issue as long as the property is only ever used for cases where it really is a webpage specifically for the location rather than for something at that location)

The alternatives get a bit messier (especially in terms of best practices), but offer more utility:

---

Option two: Publish each location as a separate Organization and link to it from each department (and, optionally, create another Concept in the Organization Type Concept Scheme to represent an Organization that is specifically a Location (Place?)).

Good:

• Each location can use all of the properties available to Organization to offer more information about itself

Bad:

• It stretches the definition of Organization somewhat (the intent of the new Concept is to help remedy this)
• You cannot point to Organizations via properties like ceterms:availableAt, which may lead to unforeseen consequences

Ugly:

• Would you use ceterms:offeredBy to point from the Course to both the department and the location?

---

Option three: Add CTID to the ceterms:Place class (which has come up a few times in other contexts) in addition to adding ceterms:subjectWebpage

Good:

• You can now reuse Places without having to repeat/duplicate them
• It may solve other use cases/issues in addition to this one

Bad:

• Since Place shows up somewhere in the graph for almost everything, there is a serious potential for data publishers to balk at the new crop of CTIDs they will have to create and maintain
• In terms of the data itself, this presents a breaking change, since arrays that currently contain objects will instead contain strings (URIs). This means changes system-wide for both publishing and consuming systems (both CE's and everyone else's).

Ugly:

• What do we do with the many thousands of Places already in the system? Republish them? Leave them as bnodes?
• How do we go to all of our partners and tell them they now need to maintain those CTIDs?

[philbarker]

I favour option 1, it seems quite natural for places to have webpages (that is web addresses as well as postal addresses). I think the ugliness lies in the use of the address property to indicate location, but I can live with that.

Aside, on ctids: having a CTID available doesn't mean we have to make it mandatory on all instances.