CEDStandards / CEDS-Ontology

The CEDS Ontology is draft project to express the Common Education Data Standards (CEDS) in Web Ontology Language (OWL).
Apache License 2.0
6 stars 0 forks source link

Relationship between Person (or Organization) and Address #15

Open philbarker opened 1 year ago

philbarker commented 1 year ago

In considering using CEDS in PESC Transcript we discussed the relationship between a Person and an Address. The the PESC transcript model we have Person --targetContactPoint-> ContactPoint --address--> PostalAddress (other forms of contact are available). see https://github.com/philbarker/transcript_jsonld/issues/6#issue-1919414425

We suggest a similar approach for CEDS because it clarifies the meaning of the address—in CEDS is it the residence of the person, or a contact address? It also makes the Address information more easily reusable as the ContactPoint object can record the contactType: two entities can use the same address for different purposes.

I'm also interested in why there is a need for different properties for a Person Address and an Organization Address?

4pins commented 1 year ago

This is one of the biggest differences between SIF Unity and CEDS. I believe that aligning this with CEDS in transcripts will help future transitions between high school and college greatly.

philbarker commented 1 year ago

The issue with the current approach taken by CEDS is, I think, illustrated by this example.

Let's say my current address is 59 ComistonRd, so I can write, for my children:

<59ComistonRd> a ceds:AddressTypeforLearnerofFamily_FatherAddress .

but it is also the billing address for my consulting company, so you might also find

<59ComistonRd> a ceds:AddressTypeForOrganization_Mailing .

and let's say it is the physical address for me (but not my child) as well

<59ComistonRd> a ceds:AddressTypeforLearnerofFamily_Physical .

and ... well, you get the idea, the same address is used for many things.

If I then get data about my child that says

<childID> ceds:hasPersonAddress <59ComistonRd>

how do I know which of those address types is the relevant one?

So, better to abstract the use of the address into an object that is less likely to be reused, which is the rationale behind ContactPoint.

<childID> :contactPoint [
   :contactType :FatherAddress
   :address <59ComistonRd>   
]

is unambiguous