Re: Domain of :key

On 1 April 2013 09:39, Henry Story <henry.story@bblfish.net> wrote:

>
> On 1 Apr 2013, at 01:55, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:
>
> >
> > On Sun 2013-Mar-31, at 20:33, Henry Story <henry.story@bblfish.net>
> > wrote:
> >
> >> No, it is a thing that does stuff. There is no problem with calling
> your web server an agent.  Browsers are called user agents, presumably
> because there are server agents. There is a whole field of programming
> called agent oriented programming.
> >
> >>> Similarly, I have applications which have their own client
> certificates for communicating with servers: these are issued specifically
> to the application so that it can authenticate autonomously with an
> identity which is deliberately distinct from any human involved in its
> development and operation. Again, describing a webapp as a foaf:Agent
> strikes me as dubious stretching of the term 'agent', there (compared to,
> say, an application which is operating under the "direction" of an
> operator).
> >>
> >> No there is no problem with that. foaf:Agent is more general that human
> agents, and so you can give a webid to a software
> >> agent and relate it via the cert:key to a public key. No problem.
> >
> > If you ascribe foaf:Agent to everything which has some property which
> means it may at some point fall within the definition given, then you end
> up applying foaf:Agent to pretty much everything…
>
> You should discuss that with Dan Brickley on the foaf mailing list if you
> think his definition is
> so close to being a owl:Thing that it's not worth having the distinction.
>
> We don't assign the domain of :key or the range of :identity to any agent,
> but to those
> for which the following is true:
>
> :identity a rdf:Property, owl:ObjectProperty;
>     vs:term_status "archaic";
>     rdfs:label "identity"@en;
>     rdfs:isDefinedBy <cert#>;
>     skos:editorialNote """
>          It turns out that this relation is unintuitive to write out and
> to name.
>          One should instead use cert:key
>     """@en;
>     rdfs:comment """
>     the identity of the public key. This is the entity that knows the
> private key and
>     so can decrypt messages encrypted with the public key, or encrypt
> messages that can
>     be decrypted with the public key.
>     """@en;
>     owl:inverseOf :key;
>     rdfs:domain :PublicKey .
>
>
> That is it has to be something that can be responsible for a private key -
> keeping
> it safe from other agents within reason, and it has to be something that
> can encrypt
> and decrypt messages with the key. Those are very clearly agent like
> things.
> Software agents can be such things.
>
> >
> > This is the distinction, I guess, between 'is defined as an agent' and
> 'has the properties of an agent' — and I suppose why X.509/LDAP has a
> distinction between 'structural' and 'auxiliary' classes (the former being
> defining qualities, the latter describing facets).
> >
> > What about, say, a piece of digital media? There are situations where
> encoded media has its own keys conforming otherwise to the ontology, and
> it's a bit of a stretch to say that *it* is an agent.
>
> Does digital media also have its private keys with which it can sign
> something? Is Holloywood going to
> encrypt digital media and add the private key to the media too, so that
> the media can then do what?
> Clearly not. So they don't conform to the ontology
>
> But perhaps this will become more obvious if you give us the use case. My
> guess is that this
> will reveal that you need a very different relation. And I am not against
> that.
>
> >
> > Flipping this around the other way, why _should_ the domain be
> restricted to foaf:Agent? What practical problems does it cause? (Noting
> that this isn't necessarily modifying the definition of a WebID, just that
> anything can have a key or even a certificate associated with it).
>
> Because we want a relation relating the Agent that is doing the encryption
> decryption using the given key.
> We have been using that since the beginning of WebID.
> Other relations are possible, and it is easy to create new ones if needed.
>

This is interesting logic so you want one relation that relates a key to a
URI and one that relates a key to an agent.  Logically they should be named
something like "key" and "agentKey", right?  The downside of this
suggestion is that implementations would need to change.

Though I think we have consensus slightly in favour rdfs : Resource


>
>
> >
> > M.
> >
> > --
> > Mo McRoberts - Analyst - BBC Archive Development,
> > Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
> > MC3 D4, Media Centre, 201 Wood Lane, London W12 7TQ,
> > 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E
> >
> >
> >
> > -----------------------------
> > http://www.bbc.co.uk
> > This e-mail (and any attachments) is confidential and
> > may contain personal views which are not the views of the BBC unless
> specifically stated.
> > If you have received it in
> > error, please delete it from your system.
> > Do not use, copy or disclose the
> > information in any way nor act in reliance on it and notify the sender
> > immediately.
> > Please note that the BBC monitors e-mails
> > sent or received.
> > Further communication will signify your consent to
> > this.
> > -----------------------------
>
> Social Web Architect
> http://bblfish.net/
>
>