Re: semantics of certainty

hi jo!
Am Freitag, den 27.05.2005, 18:29 -0700 schrieb Jo Walsh:
...
> 
> the naive approach i'm thinking of now, is just a 0-9 scheme where 9
> is almost certain and 0 is a wild stab in the dark;
> http://openguides.org/random_url/certainty/[0-9]
> 
> the closest precedent i know of is the 1-999 url based relevancy
> rating scheme that Reto used in knobot. 

This was quite an early draft. KnoBot know models relations as resources
(similarly to annotea), eg:

<rdf:Description rdf:nodeID="X13X7f242cXa3X1043d05c4ddXa3X-74ae">
    	<rdf:type
rdf:resource="http://wymiwyg.org/ontologies/knobot#Relation"/>
	<knobot:source rdf:resource="http://gmuer.ch/myplanet"/>
	<knobot:target
rdf:resource="http://moloko.itc.it/paoloblog/index.html"/>
    	<knobot:targetLabel xml:lang="de">Paolo Massa</knobot:targetLabel>
	<knobot:strength>0.6701735</knobot:strength>
    	<knobot:strengthReduction>0.0050</knobot:strengthReduction>
    	<knobot:childStrength>0.6366764</knobot:childStrength>
<knobot:comparativeStrength>0.6701735</knobot:comparativeStrength>
    <knobot:effectiveDate>1117740723235</knobot:effectiveDate>
<knobot:minimumChildStrengthReduction>0.015</knobot:minimumChildStrengthReduction>
</rdf:Description>

This approach allows to specify other properties of the relation, such

Inverse functional properties in FOAF

Greetings.

The foaf vocabulary defines some inverse functional properties (i.e. 
foaf:homepage, foaf:mbox) in order to allow users to refer to other 
people easily.

Although this makes entering foaf data much easier from a 
user-perspective (which is - without a doubt - crucial), IMvHO defining 
properties as inverse functional that may have different subject 
entities over time (mboxes as well as homepage-URLs may pass from one 
person to another) is quite a dangerous thing and may result in 
applications thinking of two different persons as one, which is 
probably not intended.

On the other hand, requiring some kind of naming authority makes 
referring to people even more cumbersome and the only other way that 
comes to my mind right now is to add something like time constraints, 
such that the maker of a foaf:PersonalProfileDocument states that a 
person he or she wants to refer to had i.e. a particular mbox at a 
given date, which would not only need some external logic and additions 
to the used vocabularies in order to be resolveable, but another 
authority to state when the person-mbox-relation became (in)valid.

One other way of understanding the specs is that foaf:mbox (if identical 
for multiple people) does semantically refer to the foaf:Group (which 
is a foaf:Agent and therefore in the domain of foaf:mbox) of people, 
who have ever owned this mbox. This would, however, result in conflicts 
with the other information usually linked to a foaf:Person owning this 
particular foaf:mbox.

Re: Inverse functional properties in FOAF

Ingomar Wesp wrote:
> One other way of understanding the specs is that foaf:mbox (if identical 
> for multiple people) does semantically refer to the foaf:Group (which 
> is a foaf:Agent and therefore in the domain of foaf:mbox) of people, 
> who have ever owned this mbox. This would, however, result in conflicts 
> with the other information usually linked to a foaf:Person owning this 
> particular foaf:mbox.

If more that one person has ever owned an email address, then that 
address isn't the valid target of foaf:mbox. Simple.

--
Regards,
Jon Hanna

"I don't like to LOOK out of the windows even - there are so many of 
those creeping women, and they creep so fast."
- Charlotte Perkins Gilman, _The Yellow Wallpaper_

_______________________________________________
rdfweb-dev mailing list
rdfweb-dev@...
wiki: http://rdfweb.org/topic/FoafProject
http://rdfweb.org/mailman/listinfo/rdfweb-dev

Re: Inverse functional properties in FOAF

Jon Hanna schrieb:
> If more that one person has ever owned an email address, then that
> address isn't the valid target of foaf:mbox. Simple.

Simple, indeed, but IMHO not entirely satisfying, because

a) this rule would require each creator/processor of a 
foaf:PersonalProfileDocument to know about the history of each mbox 
he/she includes as the object of a foaf:mbox statement, which is 
usually not the case and

b) the creator would have to know whether this mbox will _ever_ be 
transferred to another user (which would render it an illegal target), 
which is simply impossible - unless you know a really good fortune 
teller.

Or am I just not getting what you mean?

A nice weekend to you,
Ingomar Wesp

--

-- 
 ____ )) _ http://ingomar.wesp.name/ _ .. ___________ ,^\\|//^. _______
(    ((          |     ~~           |  ||            //(-#-#-)\\      (
 ) (|~~| [#### ] | ====#    [###  ] | |~~| [     ]   '|(,,^,,)|`       )
(__ '==' ________|__ (_.._)_________| |__| ___________ .\,,,/. ____iw_(

_______________________________________________
rdfweb-dev mailing list
rdfweb-dev@...

Re: Inverse functional properties in FOAF

On Sat, Jun 04, 2005 at 02:33:12AM +0200, Ingomar Wesp wrote:
> Jon Hanna schrieb:
> > If more that one person has ever owned an email address, then that
> > address isn't the valid target of foaf:mbox. Simple.
> 
> Simple, indeed, but IMHO not entirely satisfying, because
> 
> a) this rule would require each creator/processor of a 
> foaf:PersonalProfileDocument to know about the history of each mbox 
> he/she includes as the object of a foaf:mbox statement, which is 
> usually not the case and
> 
> b) the creator would have to know whether this mbox will _ever_ be 
> transferred to another user (which would render it an illegal target), 
> which is simply impossible - unless you know a really good fortune 
> teller.
> 
> Or am I just not getting what you mean?

You are understanding correctly, but the general feeling towards this
matter has always been that the users of the specification can make that
decision better than anyone else.

One of the reasons that this is not a larger problem is the source of
most adoption for FOAF: Technical circles, where people are likely to
have their own domains, or at least a persistant email address.
(danbri@... , for example, will probably never go to anyone but Dan.)
Very few people on this list have hotmail addresses, I'd guess, and
although this is probably not the case in datasets such as LiveJournal,
no one has made public a large scale foaf-based interface to LiveJournal

Re: Inverse functional properties in FOAF

Christopher Schmidt wrote:
> Some discussion on this topic at one point (post FOAF-Galway) led to
> http://www.hackcraft.net/FOAFNonIFP/ - versions of FOAF properties which
> are not IFPs, which can be used for cases where you're not able to
> determine the longer life status of the mailbox or homepage.

Heh! I really should have remembered that one! :)

--
Regards,
Jon Hanna

"I find television very educating. Every time somebody turns on the set, 
I go into the other room and read a book."
- Groucho Marx

_______________________________________________
rdfweb-dev mailing list
rdfweb-dev@...
wiki: http://rdfweb.org/topic/FoafProject
http://rdfweb.org/mailman/listinfo/rdfweb-dev

Re: Inverse functional properties in FOAF

On Sat, Jun 04, 2005 at 03:46:13PM +0100, Jon Hanna wrote:
> Christopher Schmidt wrote:
> >Some discussion on this topic at one point (post FOAF-Galway) led to
> >http://www.hackcraft.net/FOAFNonIFP/ - versions of FOAF properties which
> >are not IFPs, which can be used for cases where you're not able to
> >determine the longer life status of the mailbox or homepage.
> 
> Heh! I really should have remembered that one! :)

I'll admit I was a bit surprised you didn't at least mention it :)

--

-- 
Christopher Schmidt

_______________________________________________
rdfweb-dev mailing list
rdfweb-dev@...
wiki: http://rdfweb.org/topic/FoafProject
http://rdfweb.org/mailman/listinfo/rdfweb-dev

Re: Inverse functional properties in FOAF

Greeting again and thanks for the elaborate and helpful answers.

I understand and appreciate the pragmatic approach resulting from the 
need for simplicity, but since I tend to be overly pedantic, I'm also 
afraid of it's possible consequences (think of big web applications 
publishing their user-data in foaf).

There are currently numerous ways of uniquely identifying people, but 
unfortunately none is as simple to remember and use as the 
mbox-property. The approach suggested in 
http://www.hackcraft.net/FOAFNonIFP/ resolves the smushing-problems, 
but also drastically reduces the expressiveness of these properties.

Mhm, can't come up with something better, so I probably will have to 
live with what we've got 

--

-- 
 ____ )) _ http://ingomar.wesp.name/ _ .. ___________ ,^\\|//^. _______
(    ((          |     ~~           |  ||            //(-n-n-)\\      (
 ) (|~~| [###  ] | ====#    [###  ] | |~~| [     ]   '|(,,^,,)|`       )
(__ '==' ________|__ (_.._)_________| |__| ___________ .\,,,/. ____iw_(

_______________________________________________
rdfweb-dev mailing list
rdfweb-dev@...
wiki: http://rdfweb.org/topic/FoafProject
http://rdfweb.org/mailman/listinfo/rdfweb-dev

Re: Inverse functional properties in FOAF

Ingomar Wesp said:
> There are currently numerous ways of uniquely identifying people, but
> unfortunately none is as simple to remember and use as the
> mbox-property. The approach suggested in
> http://www.hackcraft.net/FOAFNonIFP/ resolves the smushing-problems,
> but also drastically reduces the expressiveness of these properties.

The problem isn't really limited to IFPs and shmushing.  Any information
that can go out of date can be problematic from an application's point of
view, e.g. there's no way to revoke the assertion that my foaf:mbox is
whatever, but my email address can change.

We should probably have a way of labeling documents containing RDF with
the date/time or range during which the information is known to be true. 
I haven't come across a schema meant for that, but maybe someone else has?

- Josh Tauberer

_______________________________________________
rdfweb-dev mailing list
rdfweb-dev@...
wiki: http://rdfweb.org/topic/FoafProject
http://rdfweb.org/mailman/listinfo/rdfweb-dev

CFP: Semantic Desktop WS 2005

============================CALL FOR PAPERS============================

                            1st Workshop on
                         The Semantic Desktop

          Next Generation Personal Information Management
                and Collaboration Infrastructure

                                at the
                 International Semantic Web Conference
                   6 November 2005, Galway, Ireland

                      http://www.semanticdesktop.org

=======================================================================
[Important Dates and Submission Details]
=======================================================================
* Submissions due:               August 1, 2005
* Notification for acceptance:   September 1, 2005
* Camera ready due:              October 7, 2005
* Workshop date:                 November 6, 2005

Please follow the style guides according the Springer LNCS format 
outlined at: 
http://www.springeronline.com/sgw/cda/frontpage/0,11855,5-164-2-72376-0,00.html 
Technical papers should have max. 15 pages including references, 
position papers should not exceed 5 pages. Papers can be associated with 
a demo. Please submit documents as HTML, PDF, or Word to

  semdesk2005@...