W3C home > Mailing lists > Public > public-webid@w3.org > April 2013

Re: Domain of :key

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 1 Apr 2013 17:56:03 +0200
Cc: Mo McRoberts <Mo.McRoberts@bbc.co.uk>, public-webid <public-webid@w3.org>
Message-Id: <15C4F984-D072-4F24-8107-DB649C770EFD@bblfish.net>
To: Melvin Carvalho <melvincarvalho@gmail.com>

On 1 Apr 2013, at 14:57, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> 
> 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. 

I never proposed anything about having a relation relating a key to a URI.

> Logically they should be named something like "key" and "agentKey", right?  The downside of this suggestion is that implementations would need to change.  

yes, so why not elaborate your use case, so we can discuss something seriously.

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

It is clear that there is no consensus at present. I still don't have a clear use case for why you want what
you want.

Henry

>  
> 
> 
> >
> > 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/
> 
> 

Social Web Architect
http://bblfish.net/




Received on Monday, 1 April 2013 15:56:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:43 UTC