[rdfweb-dev] Re: myers briggs

[Dan Brickley]

* Bill Kearney <wkearney99 at h...> [2002-12-14 12:56-0500]
> > From: Dan Brickley <danbri at w...>
> > Subject: myers briggs
> > So, I don't believe in such things, but it'd be fun.
> 
> Indeed. There are so many different facets that can be considered for group
> forming. I'm no believer than any of these metadata elements should be used for
> exlusionary filtering. Their presense is just another way for people to get a
> little bit more of a mental picture of others.

Yup... (alongside the digital pictures :) 

> > Hardly urgent, but I've been wondering about a namespace for such
> > things since the last time I did one of these surveys, and
> > http://weblog.delacour.net/archives/000776.html reminded me how annoying and
> > interesting this'd be, all at the same time.
> 
> I've had one in development for a while.
> http://www.ideaspace.net/users/wkearney/schema/mbti/0.1/

Ooh, I'd missed that. Excellent...

> > Easiest thing would be to create foaf:myersBriggs predicate as suggested
> > by Jim in that blog thread. Those with more time to kill could draft a
> > representation of the per-axis weightings...
> >
> > Let's do the easy thing and add a single property, as already used by
> > Jim: <myers:myersBriggs>INTP</myers:myersBriggs>
> 
> I'd imagined using <mbti:MBTI>INTP</mbti:MBTI> since there's considerable
> confusion on how to spell the name. Is it Myers or Meyers?

I asked Google, and 'Myers' seems to be reasonably dominant. 
MBTI makes me think of MBTA (Massachusetts Bay Transportation Authority), 
and more importantly it's unlikely to jog people's memory as they read it, 
whereas either spelling of 'my(e)ers briggs' might evoke a hazy memory of 
that funny personality survey thin

> > We'd need pointers to some better documentation than the quiz above, I guess.
> 
> My doc/schema does attempt to explain some of it.

Cool :)

How about proceeding with foaf:myersBriggs for the 4 letter code, and 
then everything else lives in your namespace; maybe including weightings etc
too, eventually?

> > Also worth noting that using a single flat property will make it hard to
> > query for all the "I"s or "N"s via the usual RDF APIs and query languages.
> > But same goes with geekcodes. The detail can be fleshed out in another
> > namespace later. Putting it all in a structured string might be a bit
> > unfriendly to certain RDF tools, but is a simple enough way to get started...
> 
> This was why I asked question about this a few weeks ago.
> http://groups.yahoo.com/group/rdfweb-dev/message/452
> 
> The thought being that if an RDF tool was "smart enough" to understand 
> that the acronyms are
> 
> I'd be just as happy to avoid using "yet another new namespace" and put it
> inside something like this:
> 
> <foaf:meta
> type="http://www.ideaspace.net/users/wkearney/schema/mbti/0.1#">ENTP</foaf:meta>
> 
> This would allow a fair bit of extensibility without grafting everything into
> foaf a la <foaf:kitchenSink/>. 

This kind of per-statement qualifier isn't something RDF has traditionally 
supported easily. With the most recent draft specs, there is a similar mechanism
that might be applicable: datatyping. That allows you to associate a 
URI (typically for notions such as Integer, Float, Date etc) with string values.
Ultimately I suspect that's the way to go, but for now, while datatyping 
support in tools is at an early stage, I think we need to use more specifically
named properties.

Regarding the 'kitchen sink' concern, in the glorious semwebby future I 
think I'll be inclined to agree; but for now I'm happy having FOAF be a little 
messy rather than inhibit interesting designs and apps. It is also designed to 
sit alongside much larger 'kitchen sink' vocabs (Wordnet -- 50k nouns; TAP, 
1000s of concepts) so we don't keep adding things like "Beer", "Airport" etc.



> I'm completely unsure if that's a 'valid' RDF
> statement or not. I'm open to suggestions. But it might give us an interesting
> way to extend foaf a bit.

Yes, if we adopted the datatyping syntax (similar to yours except using 
an rdf:datatype attribute). I think we need to wait for parsers and APIs 
to catch up with the specs before using that technique too heavily, though.



> On an a related tangent, Morten's got a Dublin Core "issued" date for this
> birthday. I suppose it'd be interesting to create an astrological sign element
> too. Perhaps <foaf:sign>Gemini</foaf:sign>? I could whip up a schema for it.
> It might be an interesting way to use dc:coverage temporal ranges for the
> birthdates.

I've used foaf:dateOfBirth, though don't think its in the schema yet. We 
could derrive starsigns from that. I'm definitely not an astrology believer 
but don't mind helping folk exchange such info via FOAF. We could do 
foaf:starSign or put everything in a separate schema. Hmm I wonder how many 
similar such things there are? Birthdays, geekcode, starsign, ....

If you fancy writing up a starsign schema I'll add a pointer to that from the 
spec...

cheers,

Dan


ps. am having a weekend of computing near-disasters (hardware failures etc),
so may be slow replying to some of the rdfweb-dev mail I'd hoped to get to 
at weekend... sorry!