Dan Brickley | 3 Sep 15:46 2008

[foaf-dev] [Fwd: Zing - Java Shindig based Social Networking Site (SNS)]


For folks tracking OpenSocial, this might be a nice way in. I haven't 
tried it yet, but having a layer about the raw facilities offered by 
Shindig should make things much more accessible.

BTW I recently made some experiments converting the OS schema to RDF, 
see http://danbri.org/words/2008/06/26/349   ....  Their schema is 
currently being tweaked further, for compatibility with a vcard-oriented 
project called "Portable Contacts", being led by Joseph Smarr and Chris 
Messina. I don't think this is public yet, but it will be soon and I 
think should provide us with some nice direction for future tweaks to 
the addressbook-oriented bits of FOAF.

Dan

-------- Original Message --------
Subject: Zing - Java Shindig based Social Networking Site (SNS)
Date: Wed, 3 Sep 2008 18:32:33 +0530
From: Gaurav Nigam <gaurav.impetus@...>
Reply-To: shindig-dev@...
To: shindig-dev@...

Hello All,

Zing is a open source SNS built in Java. It uses Shindig as its open social
container. Zing provides a very good basic SNS on which you can build your
own social networking website. It is licensed under Apache License 2.0.

A lot of pain has gone into keeping the application simple yet very robust
and extensible. While you can use zing as a base for your social networking
(Continue reading)

Kless | 13 Sep 21:43 2008

[foaf-dev] Suggestion for Birthday

After of looking the Birthday issue [1] I remembered that OpenID [2]
solve it so:

date of birth as YYYY-MM-DD. Any values whose representation uses
fewer than the specified number of digits should be zero-padded. The
length of this value MUST always be 10. If the End User user does not
want to reveal any particular component of this value, it MUST be set
to zero.
For instance, if a End User wants to specify that his date of birth is
in 1980, but not the month or day, the value returned SHALL be
"1980-00-00".

So the developers could let enter any of these options: "YYYY" (for
year), "YYYY-mm" (year-month) or "mm-dd" (month-day)

[1] http://wiki.foaf-project.org/BirthdayIssue
[2] http://openid.net/specs/openid-simple-registration-extension-1_1-01.html
Kless | 13 Sep 21:47 2008

[foaf-dev] firstName = givenname

I think that could be deleted the *firstName* property since that
'first name' is a synonym of 'given name'.

http://en.wikipedia.org/wiki/First_name
http://en.wikipedia.org/wiki/Given_name
Kless | 13 Sep 22:07 2008

[foaf-dev] Suggestion: biography property

I suggest to create a property called *foaf:biography* referencing to
a homepages with the biographical information.

It would better than use *bio:olb* [1] where you have to write that
information.

[1] http://vocab.org/bio/0.1/#olb
Kless | 13 Sep 22:32 2008

[foaf-dev] mbox_sha1sum describes only email

In this post [1] there is a solution for the next problem:

foaf:mbox is described of independent manner, allowing for email
message boxes, jabber message boxes and even voicemail message boxes.
But, foaf:mbox_sha1sum, is specified in such a way that only email is
permitted.

The solution is changing the description to:
---------
A foaf:mbox_sha1sum of a foaf:Person is a textual representation of
the result of applying the SHA1 mathematical functional to a URI that
they stand in a foaf:mbox relationship to. Note that the URI must be
complete, including any 'mailto:' or similar prefix.
---------

foaf:mbox could also be clarified by changing:
---------
The foaf:mbox property is a relationship between the owner of a
mailbox and a mailbox. These are typically identified using the
mailto: URI scheme (see RFC 2368) or any other scheme which defines a
protocol suitable for storing messages for an owner.
---------

[1] http://connect.educause.edu/blog/StuartYeates/foafandjabberxmpp/2398?time=1221305588
Story Henry | 14 Sep 09:16 2008
Picon

Re: [foaf-dev] mbox_sha1sum describes only email

On 13 Sep 2008, at 22:32, Kless wrote:

> In this post [1] there is a solution for the next problem:
>
> foaf:mbox is described of independent manner, allowing for email
> message boxes, jabber message boxes and even voicemail message boxes.
> But, foaf:mbox_sha1sum, is specified in such a way that only email is
> permitted.
>
> The solution is changing the description to:
> ---------
> A foaf:mbox_sha1sum of a foaf:Person is a textual representation of
> the result of applying the SHA1 mathematical functional to a URI that
> they stand in a foaf:mbox relationship to. Note that the URI must be
> complete, including any 'mailto:' or similar prefix.
> ---------

There are any number of solutions. Another solution would be to use an  
foaf:sha1sum relation that relates an object to an sha1sum of one of  
the URIs identifying it.

so one would then write

me:  foaf:mbox [ foaf:sha1sum "ksjdfksdfjlskjflskjdflskjdfskjfs" ] .

or

me: foaf:homepage [ foaf:sha1sum "xvxgsfwdfscscscdscskjkl" ] .

Henry
(Continue reading)

Earle Martin | 14 Sep 11:44 2008

Re: [foaf-dev] mbox_sha1sum describes only email

2008/9/14 Story Henry <henry.story <at> bblfish.net>
There are any number of solutions. Another solution would be to use an
foaf:sha1sum relation that relates an object to an sha1sum of one of
the URIs identifying it.

A while back I put together a vocabulary that allows for relating a file to its checksum with any particular algorithm:

http://downlode.org/Code/RDF/File_Properties/

At present it explicitly describes the subject of the checksum as a file, but I can see that you could change it to refer to generic "data", which could be typed as a file or an email address.

Of course such a solution is probably overkill for most FOAF users, but I thought it might be of interest.


Earle

--
うつつにひとめ
見しごとはあらず
Earle Martin | http://downlode.org/
_______________________________________________
foaf-dev mailing list
foaf-dev@...
http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Story Henry | 14 Sep 12:10 2008
Picon

Re: [foaf-dev] mbox_sha1sum describes only email


On 14 Sep 2008, at 11:44, Earle Martin wrote:

> 2008/9/14 Story Henry <henry.story <at> bblfish.net>
>
>> There are any number of solutions. Another solution would be to use  
>> an
>> foaf:sha1sum relation that relates an object to an sha1sum of one of
>> the URIs identifying it.
>>
>
> A while back I put together a vocabulary that allows for relating a  
> file to
> its checksum with any particular algorithm:
>
> http://downlode.org/Code/RDF/File_Properties/
>
> At present it explicitly describes the subject of the checksum as a  
> file,
> but I can see that you could change it to refer to generic "data",  
> which
> could be typed as a file or an email address.
>
> Of course such a solution is probably overkill for most FOAF users,  
> but I
> thought it might be of interest.

Note that the foaf:sha1sum solution I am proposing does not take the  
checksum of the file referenced by the
URL. Your fp:checksum has a domain of foaf:Document. The one I am  
proposing here, perhaps better named

xxx:uriChecksum would have a domain of owl:Thing, ie, anything that  
can be named.

For example it makes no sense to give a checksum of a person or   
mailbox.

[] a foaf:Person;
    xxx:uriChecksum "hjsdfsjhfskjhdfskj";
    foaf:mbox [ xxx:uriChecksum "ssdfsfsfskjlkjl;ksdf1234" ] .

Now how useful this really is is up for debate. But it would give us a  
generalisation of the
foaf:mbox_sha1sum relation .

Henry

>
> Earle
>
> -- 
> うつつにひとめ
> 見しごとはあらず
> Earle Martin | http://downlode.org/
> _______________________________________________
> foaf-dev mailing list
> foaf-dev <at> lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev

_______________________________________________
foaf-dev mailing list
foaf-dev <at> lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Dan Brickley | 14 Sep 12:23 2008

Re: [foaf-dev] mbox_sha1sum describes only email

Story Henry wrote:
> On 14 Sep 2008, at 11:44, Earle Martin wrote:
> 
>> 2008/9/14 Story Henry <henry.story@...>
>>
>>> There are any number of solutions. Another solution would be to use  
>>> an
>>> foaf:sha1sum relation that relates an object to an sha1sum of one of
>>> the URIs identifying it.
>>>
>> A while back I put together a vocabulary that allows for relating a  
>> file to
>> its checksum with any particular algorithm:
>>
>> http://downlode.org/Code/RDF/File_Properties/
>>
>> At present it explicitly describes the subject of the checksum as a  
>> file,
>> but I can see that you could change it to refer to generic "data",  
>> which
>> could be typed as a file or an email address.
>>
>> Of course such a solution is probably overkill for most FOAF users,  
>> but I
>> thought it might be of interest.
> 
> Note that the foaf:sha1sum solution I am proposing does not take the  
> checksum of the file referenced by the
> URL. Your fp:checksum has a domain of foaf:Document. The one I am  
> proposing here, perhaps better named
> 
> xxx:uriChecksum would have a domain of owl:Thing, ie, anything that  
> can be named.
> 
> For example it makes no sense to give a checksum of a person or   
> mailbox.
> 
> [] a foaf:Person;
>     xxx:uriChecksum "hjsdfsjhfskjhdfskj";
>     foaf:mbox [ xxx:uriChecksum "ssdfsfsfskjlkjl;ksdf1234" ] .
> 
> Now how useful this really is is up for debate. But it would give us a  
> generalisation of the
> foaf:mbox_sha1sum relation .

Note that the FOAF vocab already contains a foaf:sha1 property.

http://xmlns.com/foaf/spec/#term_sha1

[[
Property: foaf:sha1

sha1sum (hex) - A sha1sum hash, in hex.
Status:	unstable
Domain:	foaf:Document
The foaf:sha1 property relates a foaf:Document to the textual form of a 
SHA1 hash of (some representation of) its contents.

The design for this property is neither complete nor coherent. The 
foaf:Document class is currently used in a way that allows multiple 
instances at different URIs to have the 'same' contents (and hence 
hash). If foaf:sha1 is an owl:InverseFunctionalProperty, we could deduce 
that several such documents were the self-same thing. A more careful 
design is needed, which distinguishes documents in a broad sense from 
byte sequences.
]]

Let's leave dnaChecksum aside for now :)

Thoughts on where to go with foaf:sha1 welcomed. Note that I tried using 
it in RDFa in my homepage,

   <span rel="foaf:depiction ">
     <img src="danbri-txt.jpg" alt="danbri"
       style="float: center"
       property="foaf:sha1" 
content="58d174f20c039289544b2364c5c21295df2e4a2b"
      />
   </span>

and

<script type="text/javascript" src="jquery-1.2.3.min.js"
  property="foaf:sha1" 
content="6463e558dd79d51a2e8464806824c7bbc18c77fd"></script>

The latter was an exploration of its use to implement Douglas 
Crockford's proposal for a hash= attribute, see 
http://blog.360.yahoo.com/blog-TBPekxc1dLNy5DOloPfzVvFIVOWMB0li?p=789

Re modelling this properly, a useful test case is to consider two 
zero-byte documents. For example one whose primaryAuthor (functional 
property) was me, another (with a different creation date) made by 
someone else. This of course gets us back in FRBR territory, see 
http://en.wikipedia.org/wiki/FRBR and http://vocab.org/frbr/core

cheers,

Dan

--
http://danbri.org/
Dan Brickley | 14 Sep 12:34 2008

Re: [foaf-dev] firstName = givenname

Kless wrote:
> I think that could be deleted the *firstName* property since that
> 'first name' is a synonym of 'given name'.
> 
> http://en.wikipedia.org/wiki/First_name
> http://en.wikipedia.org/wiki/Given_name

 From First_name in the page you cite,
[[
In most European countries and in countries that have cultures 
predominantly influenced by Europe (North and South America and 
Australia), the given name usually comes before the family name (though 
generally not in lists and catalogs), and so is known as a forename or 
first name. But in many cultures of the world — such as that of Hungary, 
various cultures in Africa and most cultures in East Asia (e.g. China, 
Japan, Korea and Vietnam) — given names traditionally come after the 
family name.
]]

While I'm the first to admit FOAF's naming properties are messy (re. use 
of capitalisation, '_' etc), I think there is a justification for having 
terms for both.

First/last are (i) 'the wrong way to do it' (ii) widely used in 
addressbooks, databases etc.

Without knowing more about the relevant person, it is a mistake to 
assume that we know whether their family vs given name is usually 
presented 'first'. Nor whether something in a 'first name' field is 
family or given. For this reason, I see some value in having a field 
that faithfully preserves this messy unit of information, rather than 
mapping it approximately to a 'better' property name.

Does that make sense?

cheers,

Dan

--
http://danbri.org/

Gmane