- From: Phil Barker <phil.barker@pjjk.co.uk>
- Date: Fri, 3 May 2019 17:03:48 +0100
- To: public-talent-signal@w3.org
- Message-ID: <0a984e9c-b6d7-355c-fb39-d49ea4ac81e2@pjjk.co.uk>
Thank you Michael. That's actually the github issue for the last topic
we discussed: better more flexible coding of Occupational Category
<https://www.w3.org/community/talent-signal/wiki/Better_more_flexible_coding_of_Occupational_Category>,
not Job Start Date
<https://www.w3.org/community/talent-signal/wiki/Provide_start_date_for_job>.
Still, it's worth noting that the changes we discussed for coding
Occupational Category could be included in the next (June) release of
schema.org. You can view the pull request for that here
<https://github.com/schemaorg/schemaorg/pull/2207>, and follow the
tracking issue for the next release here
<https://github.com/schemaorg/schemaorg/issues/2239>.
Phil
On 03/05/2019 16:52, Ellsworth, Michael (DEED) wrote:
>
> All,
>
> I am assuming you all are following this relevant Github discussion,
> but just in case:
>
> https://github.com/schemaorg/schemaorg/issues/2192
>
> Thanks.
>
> *Mike Ellsworth | Program Director | CareerOneStop*
> /Department of Employment & Economic Development/
> 1st National Bank Building, 332 Minnesota Street, Suite E200, St.
> Paul, MN 55101
> Direct: 651-259-7562 Cell: 952-373-1006 TTY: 651-296-3900
> www.careeronestop.org <http://www.careeronestop.org/> |
> http://mn.gov/deed <http://mn.gov/deed>
>
> Follow DEED on Twitter <https://twitter.com/mndeed> and Facebook
> <https://www.facebook.com/mndeed>
>
> DEED-email-logo-signature-line-v3
>
> *From:*Alex Jackl [mailto:alex@bardicsystems.com]
> *Sent:* Friday, May 03, 2019 9:29 AM
> *To:* Jason Sole <jason@directemployers.org>
> *Cc:* Vicki Tardif <vtardif@google.com>; Merrilea Mayo
> <merrileamayo@gmail.com>; public-talent-signal@w3.org
> *Subject:* Re: [Spam] Re: [TalentSignal] proposal for Job Start Date
>
> Given that the schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284437137&sdata=MATGby%2F9dCUc03A2J0fpKkx4OXEuHTAW4WYf9Qcg224%3D&reserved=0>
> structure is going to be driving the search results we do need to
> decide how much noise we want to tolerate. This is our chance to lock
> down the results a little. It may mean some results won't show up
> because they weren't "tagged" properly, but I lean towards making the
> schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284437137&sdata=MATGby%2F9dCUc03A2J0fpKkx4OXEuHTAW4WYf9Qcg224%3D&reserved=0>
> tighter rather than looser.
>
>
> ***
>
> Alexander Jackl
>
> CEO & President, Bardic Systems, Inc.
>
> alex@bardicsystems.com <mailto:alex@bardicsystems.com>
>
> M: 508.395.2836
>
> F: 617.812.6020
>
> http://bardicsystems.com
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbardicsystems.com%2F&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284447146&sdata=DMCBz72P4ugbz2GhEbzx2nohDkVMLxHS1vfcVGAagJs%3D&reserved=0>
>
>
> On Fri, May 3, 2019 at 10:02 AM Jason Sole <jason@directemployers.org
> <mailto:jason@directemployers.org>> wrote:
>
> Vicki,
>
> That is a very good point - rogue input is something we definitely
> want to avoid.
>
> I think this is a situation where the symbiosis between Schema.org
> and HROpen Stds will be able to solve the problem for the JDX. If
> schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284447146&sdata=JX88uRWS7xJv%2BSWo%2FSwXtphB%2BWFyTJMNqPimr2iKQts%3D&reserved=0>
> taxonomy is text, then the user can input either a date or a
> string. The system collecting the data can then parse the data and
> make a determination as to type. On the data exchange side, HR
> Open can articulate this in JSON as a “oneOf” property:
>
> “startDate”:{
>
> “oneOf”: [
>
> {
>
> “type”:”date”
>
> },
>
> {
>
> “type”:”string”
>
> }
>
> ]
>
> }
>
> The system can then transfer the information to the recipient with
> the correct format, which can be used to trigger different logic
> based on type. When the recipient displays that info, they will be
> able to do so with the Schema.org property regardless of the
> transmission type on the backend. This would allow the user to
> input whatever value they wanted on the front end and stay in
> alignment with the schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284457160&sdata=BHcw3BOLyeOIx9wRlH%2B6MjCuft46IGfXcxWBMkmkIek%3D&reserved=0>
> property, while allowing for disambiguation on the reader side.
>
> We do something similar to this with our durationType property,
> which allows for both an ISO format or a number as values.
>
> I know we aren’t discussing modifications to the JSON backbone
> here, but I want to make sure we are able to handle the rapid
> machine to machine transfer of data. If we don’t the JDX won’t be
> as successful.
>
> Thanks,
>
> Jason
>
> *From: *Vicki Tardif <vtardif@google.com <mailto:vtardif@google.com>>
> *Date: *Friday, May 3, 2019 at 9:37 AM
> *To: *"'Jason@directemployers. org'" <jason@directemployers.org
> <mailto:jason@directemployers.org>>
> *Cc: *Merrilea Mayo <merrileamayo@gmail.com
> <mailto:merrileamayo@gmail.com>>, "public-talent-signal@w3.org
> <mailto:public-talent-signal@w3.org>" <public-talent-signal@w3.org
> <mailto:public-talent-signal@w3.org>>
> *Subject: *[Spam] Re: [TalentSignal] proposal for Job Start Date
>
> I appreciate that answer. And Dates are probably strongly
> preferred by most readers.
>
> But the reality is not everything will fit in ISO 8601 and a
> string like "ASAP" may be useful to certain readers. If we don't
> allow for Text, people will do it anyway with no guidance,
> particularly on the open web. As an example, there are many cases
> where properties expecting a Person instead get a string like
> "Jane Doe". It is up to the reader to determine whether this is
> useful or not and act accordingly. If schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284457160&sdata=BHcw3BOLyeOIx9wRlH%2B6MjCuft46IGfXcxWBMkmkIek%3D&reserved=0>
> over prescribes behavior, folks will just go off and do their own
> thing.
>
> - Vicki
>
> On Fri, May 3, 2019 at 9:27 AM Jason Sole
> <jason@directemployers.org <mailto:jason@directemployers.org>> wrote:
>
> Vicki & Merrilea,
>
> On the HROpen side of the equation, we have found it better to
> force a the field to specific format. Then you make it
> optional. This allows for an open ended posting without
> sacrificing the data integrity that fielded data grants.
>
> HR Open Standards dealt with this situation in our version 3
> specification. We added a “user defined” section in an attempt
> to be helpful and account for use cases that we hadn’t planned
> for. However, what ended up happening in practice is users
> were dropping their own structure in that field and saying
> they used the standard, even though no one receiving the file
> could do anything with it unless they knew the syntax of what
> was in user defined. It was an important lesson for us in
> maintaining the structure in structured data 😉
>
> Granted, this is also a result of a different focus between
> the two standards. HROpen Standards is primarily focused on
> machine to machine data transfer. Computers are notoriously
> bad at context. We need to consider both sides though, as the
> JDX will consist of both. I’m not opposed to keeping it open
> ended, but we will need to account for machine to machine
> transfer and how it handles variable data types in the spec.
>
> In addition, Merrilea, you are correct in that the data
> verification will be done outside the standard itself. The
> standard is what requires a particular format, but the
> software can allow for any sort of data input and validation
> it like, so long as the ending result matches the expectations
> of the standard. If we bake that in, we will restrict the
> usefulness of the standard.
>
> Thanks,
>
> Jason
>
> Thanks,
>
> Jason
>
> *From: *Vicki Tardif <vtardif@google.com
> <mailto:vtardif@google.com>>
> *Date: *Friday, May 3, 2019 at 9:12 AM
> *To: *Merrilea Mayo <merrileamayo@gmail.com
> <mailto:merrileamayo@gmail.com>>
> *Cc: *"public-talent-signal@w3.org
> <mailto:public-talent-signal@w3.org>"
> <public-talent-signal@w3.org <mailto:public-talent-signal@w3.org>>
> *Subject: *Re: [TalentSignal] proposal for Job Start Date
> *Resent-From: *<public-talent-signal@w3.org
> <mailto:public-talent-signal@w3.org>>
> *Resent-Date: *Friday, May 3, 2019 at 9:12 AM
>
> In general, when these sorts of issues have arisen, schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284467160&sdata=1ZX5WZNBGA3e8ohXcB7x%2BaI%2FKvu%2Ff%2BTWsG1lsu%2ByZCU%3D&reserved=0>
> has leaned toward making things easier for writers rather than
> readers as some data is usually better than no data. I suggest
> allowing Date or Text and let readers determine how to handle
> values like "ASAP".
>
> - Vicki
>
> On Fri, May 3, 2019 at 9:03 AM Merrilea Mayo
> <merrileamayo@gmail.com <mailto:merrileamayo@gmail.com>> wrote:
>
> I'm torn here between making this easy for people and
> making this easy for data collection. "Easy for people"
> would be any old text field, including a date input as
> text but which could be back-converted to an actual date
> on someone's receiving end, if needed. "Easy for data
> collection" would be to insist on a date-containing
> format, but preceded by "on or before." What this forces,
> for the vague "ASAP" cases, is for people to figure out,
> well...how long is this hiring process actually likely to
> take, and so how soon could someone be feasibly expected
> to start? That kind of planning doesn't come naturally to
> folks, but it is something that a data/software rule would
> force them into, and which would be helpful for all sorts
> of data collection and analysis. Having those dates would
> help out economists calculating trends in labor shortages,
> hiring efficiency, and frictional unemployment (the
> employment that exists because people are between jobs; a
> lot of time, this is related to how long it takes
> employers to find and hire people). There's less
> information to work with when it's an ad with a start date
> of "ASAP." Job ads are often up for a month, long after
> someone was actually hired, because the major job boards
> have you pay by the month and allow you to keep a posted
> job up for that whole time. Human laziness being what it
> is, the employer doesn't bother to take it down once the
> job is filled. Having to specify a near-term start date,
> then keep changing it as the employer couldn't find
> someone, would send much stronger market signals and
> provide more useful economic information. "ASAP" gives no
> distinction between employers needing someone in a week
> vs. employers needing someone in a month. If US hiring
> were to plunge into crisis mode, economists wouldn't be
> able to tell for quite a while - not until BLS survey
> reports came in.
>
> For the US, ASAP probably boils down to "within 2 weeks,"
> (i.e., for today's date: "on or before" 5/17/2017"), just
> because most people in the US have to give 2 weeks'
> notice. However, I would have no idea what "ASAP" meant
> for a job posting in another country whose time sense and
> customs were different.
>
> So I see the benefits of requiring a date for all sorts of
> data-related reasons, but it does make life more annoying
> for the hiring managers posting job ads. They'd have to
> think through what they really needed and estimate their
> process duration in order to supply a date.
>
> Merrilea
>
> On 5/3/2019 6:56 AM, Phil Barker wrote:
>
> Thanks Joseph, I know what you mean. It is possible to
> stipulate values, but there's a trade-off in terms of
> in terms of ease of adoption and the amount of
> justification that schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284467160&sdata=1ZX5WZNBGA3e8ohXcB7x%2BaI%2FKvu%2Ff%2BTWsG1lsu%2ByZCU%3D&reserved=0>
> might require for the changes we request. Also,
> there's more than one way of doing it
>
> Option 1 (weakest, easiest): restate the the second
> sentence of the definition to be more assertive "Text
> values "Immediately", "As soon as possible", "Any
> time" must be used when a specific date is not
> appropriate.
>
> -- one issue with this is that it's not friendly to
> non-English speakers
>
> Option 2: add an enumeration to schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284477169&sdata=pthI%2FAM%2Far0Aus2pieR6nqdeQTmEnUxPZu4Qmc%2FIUqg%3D&reserved=0>
> of jobStartDateTypes, these are URIs in the schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284477169&sdata=pthI%2FAM%2Far0Aus2pieR6nqdeQTmEnUxPZu4Qmc%2FIUqg%3D&reserved=0>
> namespace that represent the values we want. As with
> option 1 we would need to define a set of values.
> (Option 2a, allow any URI or defined term so that the
> enumeration doesn't have to be in the schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284487174&sdata=GYd9STNuvGFMe4z1nbJNjjQ8xfr7291rGbCwAGtSS4k%3D&reserved=0>
> namespace)
>
> -- one issue with this is that, as far as I know, such
> enumerations in schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284487174&sdata=GYd9STNuvGFMe4z1nbJNjjQ8xfr7291rGbCwAGtSS4k%3D&reserved=0>
> are rarely implemented, and perhaps not understood, by
> end users; we will still get people using text values.
> (BTW, that's probably going to be true what ever we do)
>
> Option 3: add a second property to indicate
> immediateStart with a boolean T/F
>
> -- one issue with this is that it is not extensible,
> we couldn't keep adding more and more properties for
> other special cases in the way that we could for the
> other options. FWIW, this is what the data model for
> the Job data exchange does. I think that
> 'immediate/asap' is the most important option
>
> Thoughts everyone?
>
> Phil
>
> On 02/05/2019 16:12, Joseph D. Marsh wrote:
>
> I like the idea of an “ASAP” option, but wonder if
> it’s possible to stipulate a single value to
> represent that idea, rather than leave it open to
> “local interpretation”?
>
> Thanks,
>
> - Joseph
>
> *From:* Phil Barker <phil.barker@pjjk.co.uk>
> <mailto:phil.barker@pjjk.co.uk>
> *Sent:* Thursday, May 2, 2019 11:03 AM
> *To:* public-talent-signal@w3.org
> <mailto:public-talent-signal@w3.org>
> *Subject:* [TalentSignal] proposal for Job Start Date
>
> Hello all, the second relatively simple issue that
> we prioritized, is that currently
> schema.org/JobPosting
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2FJobPosting&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284497188&sdata=PFrtToqd0tz4CW2kr3kT48YU49rzM2IS7yPtrY73%2FCk%3D&reserved=0>
> has no way to specify the expected start date for
> the job being advertised.
>
> A simple way to fix this
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2Fcommunity%2Ftalent-signal%2Fwiki%2FProvide_start_date_for_job&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284497188&sdata=pv7ci%2B7P9oz4g6U%2BjfQX4mJiKs%2FSMQrA2rlNqsJxTJc%3D&reserved=0>
> is a new property of JobPosting:
>
> *jobStartDate*
>
> *Definition: *The date on which a successful
> applicant for this job would be expected to
> start work. Text values such as "Immediately"
> or "As soon as possible" may be used when a
> specific date is not appropriate.
>
> *Expected type:* ISO 8601 Date
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fschema.org%2FDate&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284507188&sdata=9AYnLmHzeskcv37px3Aj091JJofx0B%2FInGwQyzvRyX0%3D&reserved=0>
> or Text
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fschema.org%2FText&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284507188&sdata=i%2FVIQF49mehUeHvH96v1puvKSns%2BmKV92nwaXpYBGA8%3D&reserved=0>
>
> Please let me know if you wish to improve on this
> or have an alternative suggestion. In particular,
> is a text value to indicate an immediate start
> sufficient, or should this be handled more
> explicitly, for example as a separate property?
>
> On that question, my own view (as exemplified in
> the proposal) is that, while an explicit indicator
> for immediate start may be useful for internal
> systems, a text value is adequate for advertising
> this on the web. If experience and demand show
> that this approach is not adequate, we would have
> evidence to provide to schema.org
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284517198&sdata=A4ycuxd%2BRW4Rs15nfdBsXiydRoAJ58KJfnDQKib3nek%3D&reserved=0>
> for a separate, explicit property.
>
> Regards, Phil.
>
> --
>
> Phil Barker
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpeople.pjjk.net%2Fphil&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284517198&sdata=3X0t7r8rFX4ow%2Fot54civ6OG%2F%2F3jwMOr56ExRUTZIes%3D&reserved=0>.
> http://people.pjjk.net/phil
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpeople.pjjk.net%2Fphil&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284527198&sdata=5G4aL8wEeGdb8y96iO3uKBwLh6fcdvWrJxwPV17mz54%3D&reserved=0>
> CETIS LLP
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cetis.org.uk&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284527198&sdata=SOF8LRWxtdgezX23zbTi7UsOo%2BPPodsF3gTUOaVRtwc%3D&reserved=0>:
> a cooperative consultancy for innovation in
> education technology.
> PJJK Limited
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pjjk.co.uk&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284537216&sdata=vPB294EB7xmNI3lucoKILoLgPPXIRa%2F3wyPEP0Jw3z0%3D&reserved=0>:
> technology to enhance learning; information
> systems for education.
>
> CETIS is a co-operative limited liability
> partnership, registered in England number OC399090
> PJJK Limited is registered in Scotland as a
> private limited company, number SC569282.
>
> --
>
> Phil Barker
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpeople.pjjk.net%2Fphil&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284547221&sdata=H4VTEZ5WDXa0F4yyTgFGwSz3xFJ%2FdcRNXeUA%2B3HjpA0%3D&reserved=0>.
> http://people.pjjk.net/phil
> <https://gcc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpeople.pjjk.net%2Fphil&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284547221&sdata=H4VTEZ5WDXa0F4yyTgFGwSz3xFJ%2FdcRNXeUA%2B3HjpA0%3D&reserved=0>
> CETIS LLP
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cetis.org.uk&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284557221&sdata=IN4jQWvwbFH%2BNbDlKqwcTD5TTTyol%2B3ypldzMhRcR1A%3D&reserved=0>:
> a cooperative consultancy for innovation in education
> technology.
> PJJK Limited
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pjjk.co.uk&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284557221&sdata=XlI7%2BPjHo7202Qy4bCbtNumK4hC%2BghVCEM3RQk03qPU%3D&reserved=0>:
> technology to enhance learning; information systems
> for education.
>
> CETIS is a co-operative limited liability partnership,
> registered in England number OC399090
> PJJK Limited is registered in Scotland as a private
> limited company, number SC569282.
>
> --
>
> Merrilea J. Mayo, Ph.D.
> Mayo Enterprises, LLC
> 12101 Sheets Farm Rd.
> North Potomac, MD 20878
>
> merrileamayo@gmail.com <mailto:merrileamayo@gmail.com>
> https://merrileamayo.com/
> <https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmerrileamayo.com%2F&data=02%7C01%7Cmichael.ellsworth%40state.mn.us%7C67deeeaeb12f4c4061cb08d6cfd3e2ce%7Ceb14b04624c445198f26b89c2159828c%7C0%7C0%7C636924906284567226&sdata=ZUkgKkKuyOAlouoyuLF03V%2FZHlGMMxdFahXx0%2FjY96c%3D&reserved=0>
> 240-304-0439 (cell)
> 301-977-2599 (landline)
>
--
Phil Barker <http://people.pjjk.net/phil>. http://people.pjjk.net/phil
CETIS LLP <https://www.cetis.org.uk>: a cooperative consultancy for
innovation in education technology.
PJJK Limited <https://www.pjjk.co.uk>: technology to enhance learning;
information systems for education.
CETIS is a co-operative limited liability partnership, registered in
England number OC399090
PJJK Limited is registered in Scotland as a private limited company,
number SC569282.
Received on Friday, 3 May 2019 16:04:17 UTC