sshkey missing in person and team RDF content

this would allow grabbing of sshkeys for login and various other things via rdf without screen-scrapping the html that is fragile and puts more requests ( for MOTU its 90+ vs one ) when using it for the MOTU community build network auth scripts .

The above is not part of the web of trust RDF specification (http://xmlns.com/wot/0.1/). If we add this feature, it'd need to be part of our own RDF namespace.

+1 for this bug, especially nick information. Without it, the team foaf output is really one-way - no way to get back to individual records in launchpad.

The nick information is already in the rdf output for a person, and no new rdf namespace work would
seem necessary to put it in the team output also.

For ssh, the foaf folks (or me if necessary) would probably be happy to consult on the best schema for doing this.

I'd suggest adding timezone information also to the personal rdf and perhaps to the team rdf, to help with meeting scheduling. That way we could make a mashup of the timezones of everyone on a team and the meeting planner at http://timeanddate.com/worldclock/meeting.html

ical/rdf has timezone descriptions.

I don't care about the SSH key information in the RDF, which is easy to get iff(!) foaf:nick support is included. It would be nice if this could be included into LP ASAP.

Should we file a seperate bug about the foaf:nick info for team members?

I can do this and it is easy, but is the use of hasSSH/PubSSH/Key elements standardized? I was thinking like something along the lines of:

<wot:hasSSHKeys><wot:PubSSHKey>AAAAB3NzaC1kc3MAAABBAL5VoWG5sy3CnLYeOw47L8m9A15hA/PzdX2u0B7c2Z1ktFPcEaEuKbLqKVSkXpYm7YwKj9y88A9Qm61CdvI0c50AAAAVAKGY0YON9dEFH3DzeVYHVEBGFGfVAAAAQCoe0RhBcefm4YiyQVwMAxwTlgySTk7FSk6GZ95EZ5Q8/OTdViTaalvGXaRIsBdaQamHEBB+Vek/VpnF1UGGm8YAAABAaCXDl0r1k93JhnMdF0ap4UJQ2/NnqCyoE8Xd5KdUWWwqwGdMzqB1NOeKN6ladIAXRggLc2E00UsnUXh3GE3Rgw==</wot:PubSSHKey>

With multiple stanzas for multiple keys. Incidentally, why do you screenscrape this, today?

FWIW, you can get the sshkeys without needing to scrape at https://edge.launchpad.net/people/+me/+sshkeys

To create an authorized_keys file on Ubuntuwire based on LP accounts.

Yeah Michael, now as we have foaf:nick due to another bug report.

Still need some guidance here to do something actually useful. Or is this bug no longer relevant?

On Thu, 2007-12-06 at 20:53 +0000, Christian Reis wrote:
> Still need some guidance here to do something actually useful. Or is
> this bug no longer relevant?

There is no list of SSH keys for a team, as far as I can see. At the
moment, one must retrieve the nicks from /~team/+rdf, then construct and
retrieve a lot of +sshkeys URLs. If the keys were in +rdf, it would be
much quicker and simpler to do, and would have less chance of getting
hosts blocked by LP (it has happened before)...

--
William Grant
Ubuntu Developer

I asked James H. for his opinion here, and he wrote me this:

There are two ways we could export the data as valid RDF. One is to
have a string property for the public key hanging off the person:

    <foaf:Person>
        <lp:sshPubKey>ssh-rsa ....</lp:sshPubKey>
        ...
    </foaf:Person>

Or we could expose the key as an RDF resource, similar to the PGP keys:

    <foaf:Person>
        <lp:hasSSHKey>
            <lp:SSHKey>
                <lp:keyType>ssh-rsa</lp:keyType>
                <lp:keyText>...</lp:keyText>
                <lp:keyComment>...</lp:keyComment>
            </lp:SSHKey>
        </lp:hasSSHKey>
        ...
    </foaf:Person>

The nesting of elements in RDF basically goes "object, property,
object, property ...", so this defines a single SSHKey and relates it
to the given person. For multiple keys, you'd need multiple hasSSHKey
property elements (rather than multiple SSHKey elements in a single
hasSSHKey element).

For the use cases in the bug, a simple string property would be
enough. The more structured form might be more useful if someone was
actually working with RDF tools.

Have a fix in PQM...

Fixed in RF 6447. Enjoy it on edge tomorrow!