Re: Domain of :key

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.

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.


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