Migration scripts for major changes in 13.0.0

[rjyounes]

Phil has created migration scripts for the units and magnitudes model (PR #1071), so no need to deal with those.

Major changes requiring migration scripts:

• Address model - ask Dan, Dylan, Michael, or me for help
  • Minimally change hasCommunicationAddress to hasAddress. Work with Dan to see what else can be automated.
• geo-predicate names - PR Remove occupies predicates and shorten isGeographicallyContainedIn  #1085
• Inverses - PR Change direction of some inverse pairs #1083
• Remove sensor-related terms - PR Removes sensor-related terms to fix issue 462 #1089 - no migration here, they will just have to stop using them

Thanks!

[rjyounes]

@DanCarey404 is away until July 5, please consult @rjyounes, @dylan-sa, @kchastain703, or @uscholdm to see what changes, if any, can be automated.

[uscholdm]

@DanCarey404 is away until July 5, please consult @rjyounes, @dylan-sa, @kchastain703, or @uscholdm to see what changes, if any, can be automated.

This would take some time to figure out what is possible and then to write the scripts. I suspect that there may be a few things that are automatable.

[rjyounes]

Sample triples:

1. geo-predicate names - PR Remove occupies predicates and shorten isGeographicallyContainedIn  #1085

ex:_City_minneapolis gist:isGeographicallyContainedIn ex:_State_minnesota => ex:_City_minneapolis gist:isGeoContainedIn ex:_State_minnesota 

ex:_thing1 gist:occupiesGeographicallyPermanently ex:_thing2  => ex:_thing1 gist:hasPhysicalLocation ex:_thing2 

ex:_thing1 gist:occupiesGeographically ex:_thing2  => ex:_thing1 gist:hasPhysicalLocation ex:_thing2 

2. Inverses - PR Change direction of some inverse pairs #1083

ex:_Collection_1 gist:hasMember ex:_Person_1 => ex:_Person_1 gist:isMemberOf ex:_OrderedCollection_1

ex:_OrderedCollection_1 gist:hasFirstMember ex:_OrderedMember_1 => ex:_OrderedMember_1 gist:isFirstMemberOf ex:_OrderedCollection_1

ex:thing1 gist:hasPart ex:thing2 => ex:thing2 gist:isPartOf ex:thing1 

ex:thing1 gist:hasDirectPart ex:thing2 => ex:thing2 gist:isDirectPartOf ex:thing1 

3. Address model - PR Added updates for addresses #1106

ex:_Person_1 gist:hasCommunicationAddress ex:_Address_1 => ex:_Person_1 gist:hasAddress ex:_Address_1

ex:_Address_1 a gist:ElectronicMessageAddress => ex:_Address_1 a gist:ElectronicAddress

ex:_Address_2 a gist:EmailAddress => ex:_Address_2 a gist:ElectronicAddress

ex:_Address_3 a gist:TelephoneNumber => ex:_Address_3 a gist:ElectronicAddress

ex:_Address_4 a gist:StreetAddress => ex:_Address_4 a gist:PhysicalAddress

ex:_Address_5 a gist:PostalAddress => ex:_Address_5 a gist:PhysicalAddress

(Don't worry that it appears we're losing meaning here; we have added category classes which need to be instantiated by users in order to provide those semantics and more. Those triples can't be added by the scripts because we have only defined the classes; categories will have to be defined in the user's namespace.)

[rjyounes]

@kchastain703 @uscholdm @dylan-sa @pwin Can one or more of you confirm that the address examples are correct and as complete as they can be given the shift towards user-defined categories? Thanks.

[uscholdm]

Don't worry that it appears we're losing meaning here; we have added category classes which need to be instantiated by users in order to provide those semantics and more. Those triples can't be added by the scripts because we have only defined the classes; categories will have to be defined in the user's namespace

That's mostly true, however we could provide samples indicating how it would work. Maybe not a good idea, better left to the usage documentation.

[uscholdm]

Can one or more of you confirm that the address examples are correct and as complete as they can be given the shift towards user-defined categories? Thanks.

I just confirmed that the examples are correct.

[kchastain703]

@kchastain703 @uscholdm @dylan-sa @pwin Can one or more of you confirm that the address examples are correct and as complete as they can be given the shift towards user-defined categories? Thanks.

for the first example, gist:CommunicationAddress currently covers mailing addresses as well as email addresses (that is, anywhere someone wants to receive communications), so it will not necessarily always migrate from CommunicationAddress to ElectronicAddress

[uscholdm]

for the first example, gist:CommunicationAddress currently covers mailing addresses as well as email addresses (that is, anywhere someone wants to receive communications), so it will not necessarily always migrate from CommunicationAddress to ElectronicAddress

There is no gist:CommunicationAddress. ALso, it is true that a non-person can have an address, e.g. an organization. Also, it is not clear whether you intend for the IRIs to snap together. So the pattern will be more like

• ex:_Thing_0 gist:hasCommunicationAddress ex:_Address_0 => ex:_Thing_0 gist:hasAddress ex:_Address_0

[rjyounes]

it is not clear whether you intend for the IRIs to snap together.

Each line of the exx above is meant to be read independently. The requirement is just for test triples to test the migration scripts.

That's mostly true, however we could provide samples indicating how it would work. Maybe not a good idea, better left to the usage documentation.

I am planning to write a narrative migration doc along the lines of what Phil is doing for uoms in PR #1110. See new issue #1109. The intent was for this to have been done in addition to the model explanation in the gist-doc repo, but that is not what happened, so I will do it unless you want to volunteer.

[rjyounes]

It is not enough to have in the usage documentation in gist-doc. Users will expect some instructions on how to migrate, they are not going to go looking there to puzzle it out.

[kchastain703]

Oh okay, I was misinterpreting the examples, sorry. The example triple patterns look good to me.

[rjyounes]

ALso, it is true that a non-person can have an address, e.g. an organization

How is this relevant? These are example triples used to test the migration script. It makes no difference what the type of the subject is (which incidentally is not necessarily gist:Person just because of the infix, it has not been asserted).

[uscholdm]

How is this relevant? These are example triples used to test the migration script. It makes no difference what the type of the subject is (which incidentally is not necessarily gist:Person just because of the infix, it has not been asserted).

It was not immediately obvious to me whether the midfixes were meant to be significant and intended to be in any of the migration queries. Apparently, they are not.

[philblackwood]

We also need to include scripts to convert to using gist:offers. Working on it.