Re: Domain of :key

On 31 Mar 2013, at 21:16, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:

> 
> On Fri 2013-Mar-29, at 23:48, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
>>>>>>> Let's consider Mo's proposal just to widen the range to something like rdfs : Resource
>>>>>>> 
>>>>>>> A WebID can still be an agent, yes?
>>>>>> 
>>>>>> yes.
>>>>>> 
>>>>>> good
>>>>>> 
>>>>>> 
>>>>>> The problem is that you need to define how for some object X you relate it to the private key.
>>>>>> In order to distinguish your definition from the current one, so that we don't have misunderstandings
>>>>>> let us call your relation mlv:key .
>>>>>> 
>>>>>> mlv:key a rdf:Property;
>>>>>>     rdfs:domain rdfs:Resource;
>>>>>>     rdfs:range cert:Key .
>>>>>> 
>>>>>> fine
>>>>>> 
>>>>>> 
>>>>>> Now that means I can relate any object to a key. For example why could I not take the Eiffel Tower,
>>>>>> and write:
>>>>>> 
>>>>>>     dbpedia:EiffelTower mlv:key <http://bblfish.net/people/henry/card#key1> .
>>>>>> 
>>>>>> why could you not?  you just did
>>>>> 
>>>>> Indeed you can. So if you want you can publish the mlv:key ontology in your namespace.
>>>>> Perhaps it will get traction.
>>>>> 
>>>>> The point of writing ontologies for reasoning is that you don't just stop at that point.
>>>>> You can relate anything to anything by some relation.  The problem is distinguishing your
>>>>> mlv:key relation from every other relation. What distinguishes it from
>>>>> 
>>>>> mlv:loves
>>>>> mlv:saw
>>>>> mlv:wantToOwn,
>>>>> 
>>>>> etc...  You need to do the work of defining it. And when you do that you'll start seeing that
>>>>> your problems start building up, as shown below.
>>>>> 
>>>>> Please reread what you wrote.  First you said you can not, now you say you can.  This makes little sense.
>>>> 
>>>> I am developing the consequences of your proposal. mvn:key does what you want.
>>>> But does it do what WE need it to do? My argument is that it does not make things simpler
>>>> as you claimed it does. In fact it raises a whole bunch of issues, and puts work on our
>>>> plate for a benefit that is completely hypothetical.
> 
> Right, but there are a couple of different issues here.
> 
> Publishing an alternative ontology which differs only in having a broader range isn't an especially useful use of anybody's time, particularly if the narrow range of the original ontology is specified because nobody thought it might be useful in the broader case, rather than because it fundamentally alters the effects when used with the classic use-cases.
> 
> Given the generic nature of the cert and key ontologies, it makes little sense to consider changes solely within the context of WebID (as distinct from considering whether they might cause *problems* for WebID). It helps nobody to have thirty-seven different ontologies for representing in more or less the same way something which is fundamentally defined externally.
> 
> I proposed broadening the range to rdfs:Resource because I can think of a range of cases where keys "belong" to things which aren't usefully described as foaf:Agents.

http://xmlns.com/foaf/spec/#term_Agent
"The Agent class is the class of agents; things that do stuff."

> For example, a server listening for SSH connections has its own identity (the so-called "host key").  Once could _theoretically_ claim that the server was a foaf:Agent operating on behalf of the owner/administrator, but if you do that you risk diluting the meaning of foaf:Agent to the extent that it becomes utterly meaningless.

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.

> 
> Does that clarify things?

It does. It strenthens the argument that we don't need to go beyond foaf:Agent. That is a very general class of things.


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