Re: Domain of :key

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

> 
> 
> 
> On 1 April 2013 20:57, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 1 Apr 2013, at 20:49, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:
> 
> >
> > On Mon 2013-Apr-01, at 14:12, Dominik Tomaszuk <ddooss@wp.pl> wrote:
> >
> >> In which point rdf:Resource is better than owl:Thing? I do some ontology state-of-the-art and I don't see too much ontologies with uses rdfs:Resource in rdfs:domain or rdfs:range. My conclusion to these aproaches is that rdfs:Resource is used in low-level ontologies and cert ont isn't in that level. Probably better consensus is owl:Thing.
> >> Of course, I don't change my mind and I still think that foaf:Agent is better.
> >
> > I'd contend that the cert ont _is_ (or at least, could easily be and arguably should be) a low-level ontology: it exists to describe keys and certificates. I don't see a sensible reason why the domain of the things keys and certificates described by it are associated with shouldn't be as broad as possible unless there's a good reason not to — and I'm at this point not entirely understanding what that reason might be.
> 
> Because there is a specific relation of agents to keys, such that the agent is in control of the key.
> This is what WebID needs.
> 
> If you need another relation from a anything to a key, there are many functions
> 
> - rdfs:seeAlso
> - rdfs:member
> - xxx:signedWith
> - xxx:encryptedWith
> - xyz:myOwnerHasKey
> - xdw:ILikeThisKeyButITsNotMine
> - etc...
> 
> 
> >
> > I don't have a strong feeling on owl:Thing versus rdfs:Resource, except that it's not particularly clear what benefit is derived from restricting it to owl:Thing.
> >
> > There's a school of thought evident in this thread that one solution is to define another ontology which is identical to the cert ontology except for the domain of the things keys and certificates can be associated with. I don't buy that — it breaks interop. While semweb is, as Kingsley says, "fork friendly", there is still a cost associated with that (and in this case it's divisiveness).
> 
> The school of thought is that we have a use case for the relation we have defined. It has been clearly
> defined and we find it useful. You have not defined the use case for your relation, or at least you
> have only been handwaving in the direction.
> 
> We may find that you don't need a new relation at all but that you can compose it with other existing ones..
> 
> 
> You've been given many use cases.  You are trying to dismiss arguments by labeling them 'handwavy'.  
> 
> I'll repeat one.  Facebook integration.  You dont have much of a social system if you design it to exclude facebook.

We have not excluded Facebook here at all.  

> 
> The correct way is to include BOTH facebook and WebID not pick a winner.  I say this is a bug, the onus is on you to come up with a convincing argument for exclusion.

Well given that we have not excluded facebook I don't see that you have a point.

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