[Buildingdata] Re: [opendata] {Disarmed} Re: [opendata] Vacancies

[Alexander Dutton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[CCed to buildingdata]

[Sorry to anyone who gets bored with RDF and ontologising! Feel free
to glaze over…]

Hi Chris,

On 12/08/11 13:08, Christopher Gutteridge wrote:
> ooooo, that RDF is a bit hacky :)

Yes, maybe. We should probably have said "early preview", "work in
progress", "subject to change", etc.

>
> If I appear to have a bunch of complaints, it's more that I've
> been hoping someone would do some work on such a schema, so I hope
> you'll not be put off!

Feedback is always appreciated ;-). Us lot will start drafting it on
the wiki (for RDF bods who don't know about it already, it's at
<http://openorg.ecs.soton.ac.uk/>; e-mail Chris for an account).

>
> <j.2:closingDate rdf:datatype=*MailScanner has detected a possible
> fraud attempt from "www.w3.org" claiming to be*
> "http://www.w3.org/2001/XMLSchema#date">2011-08-12</j.2:closingDate>
>
>
<j.2:salary_grade>4</j.2:salary_grade>
>
> I'd suggest that at the very least you pick "_" or camelCaps. Rule
> of thumb for the openorg namespace is camelCaps with upper case
> first letter for clases, and lower case for predicates.

Yep.

>
> Also can you have a bit more discussion before making stuff up
> under openorg -- I'm keen to be flexible, but this really needs
> some work.

Sorry about that. In our defence it's not open to the world yet ;-).
Hopefully this will start a discussion on the openorg mailing list
(<http://mailman.ecs.soton.ac.uk/mailman/listinfo/buildingdata> for
any curious folk).

> Maybe should be: applicationClosingDate and perhaps
> applicationOpeningDate and even
> applicationInterviewNotificationByDate

Yes, all makes sense (I think). The opening date is currently (well,
should be) encoded as dcterms:created, as I don't think the vacancy
opens any later than it's first published.

>
> and the other end with: postEarliestStartDate postLatestStartDate
> and postDuration

I don't think we have these available in any sane form, but yes,
sensible things to define.

>
> also
>
> -- full time, part time, temp, intern, maternity/paternity cover
> etc. -- fixed contract? -- salary, hourly pay -- benefit (eg.
> health cover, holidays etc.) -- bonuses?

Again, all good (if someone can come up with some sane model).

>
>
>
> <j.2:salary_grade>4</j.2:salary_grade> Salary grade is a very vague
> term. Probably our Grade 4 doesn't match your grade 4... I would
> suggest that a grade is actually a URI, or at the very least should
> have a datatype to indicate it's the oxford university 2011 grades
> scheme.

I agree. I have actually started turning our salary scales
(<http://www.admin.ox.ac.uk/finance/payroll/scales/>) into RDF (giving
each grade/pay-point URIs), but that'll need more vocabulary
standardisation.

> eg. <j.2:salaryGrade><j.2:Grade
> rdf:about="http://oxpoints.oucs.ox.ac.uk/grade/4"> <rdf:label>Grade
> 4</rdf:label> <j.2:gradeNumber rdf:datatype=*MailScanner has
> detected a possible fraud attempt from "www.w3.org" claiming to
> be* "http://www.w3.org/2001/XMLSchema#integer">4</j.2:gradeNumber>
>
> <j.2:within
> rdf:resource="http://oxpoints.oucs.ox.ac.uk/id/23232568"/>
> Confusing term. I guess it means the organisational Element you'll
> be working in? perhaps j.2:organizationPart ?

True.

> <j.2:employer
> rdf:resource="http://oxpoints.oucs.ox.ac.uk/id/00000000"/> Hmm.
> Probably OK.

Only probably? :P. Incidentally, we have some jobs where there will be
two employers (academic roles which are joint appointment between a
college and the University), so people may start seeing two employer
properties.

>
> <j.2:salary_upper>22971</j.2:salary_upper>
> <j.2:salary_lower>19822</j.2:salary_lower> Doesn't list what
> currency (steal that from good relations?) What about part time
> jobs, is this the Full Time Equivalent salary.

Yes. Again, started to look at this in the pay scale modelling, but it
needs more thinking about. I was intending to use GR for the
currency/value stuff.

> <j.2:modified rdf:datatype=*MailScanner has detected a possible
> fraud attempt from "www.w3.org" claiming to be*
> "http://www.w3.org/2001/XMLSchema#date">2011-08-08</j.2:modified>
> <j.2:created rdf:datatype=*MailScanner has detected a possible
> fraud attempt from "www.w3.org" claiming to be*
> "http://www.w3.org/2001/XMLSchema#date">2011-08-01</j.2:created>
> Could this just be dcterms:created and dcterms:modified?
>
> <j.2:furtherParticulars
> rdf:resource="http://data.ox.ac.uk/id/vacancy/100748/file/0"/>
> Could this just be foaf:page?

Not sure. vacancy:furtherParticulars could be rdfs:subPropertyOf
foaf:page. Also, we were planning on having it available in multiple
formats (e.g. the original Word, PDF and plain text), so it's probably
a Expression in FRBRland, not a Manifestation. Really these should be
something like e.g. <http://source.data.ox.ac.uk/vacancy/100748/0> and
<http://source.data.ox.ac.uk/vacancy/100748/0.doc>.

>
> <j.2:description> … </j.2:description> This really should be
> dcterms:description unless there's a reason not to.

Indeed it should.

>
> <j.2:online>True</j.2:online> eh? <j.2:open>True</j.2:open> eh?

"whether it's advertised on the website" and "whether the closing date
has passed". These (if we have them at all) should certainly be
xsd:booleans. It's arguable that the open stuff is redundant (and
potentially misleading) if we also have the actual closing date.

>
> Also really needs to add in something about the location the job is
> in. foaf:based_near?

Yes, that would be cool to have. At the moment you can vaguely get at
it through vacancy:within/org:hasSite, but that breaks down — and
we're throwing information away — when an org has more than one site.

> Also needs to add something for max/min hourly rates on jobs with
> wages.

Presumably that sits in the salary modelling stuff somewhere…

> Also needs something about requirements.

Yes. Not available to us unless we parse the Word document (*joy*).


Also, kudos to MailScanner. I'll know to look out for your fraud
attempts in future.


Yours,

Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk5FHugACgkQS0pRIabRbjDQlwCcCe6VrWKmXmhLF1t2i4sL/oKm
1i8AnA/YMmdMlbUdjbjjmCog7zd+//IW
=FB+F
-----END PGP SIGNATURE-----