Melvin Carvalho | 6 Jul 2010 01:33
Picon
Gravatar

[foaf-dev] Happy FOAF of July!

Happy Holiday, for all those that had one! :)

_______________________________________________
foaf-dev mailing list
foaf-dev@...
http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Dan Brickley | 9 Jul 2010 13:27

[foaf-dev] Fwd: [Social-discuss] Announcing P2P GNU Social

Another interesting project! and apparently some code already...

Dan

---------- Forwarded message ----------
From: Ted Smith <teddks@...>
Date: Fri, Jul 9, 2010 at 1:21 PM
Subject: [Social-discuss] Announcing P2P GNU Social
To: social-discuss <social-discuss@...>, social <social@...>

For the past few weeks, Miron Cuperman and I have been thinking about
how to do social networking in a p2p and privacy-enhanced way. We've
come up with some code and documents that describe a distributed social
networking system that is able to make and enforce strong guarantees
about user privacy while still providing usability in the same vein as
traditional, centralized or hub-and-spoke services. We've collected this
into an effort to build a P2P GNU Social.

The GNU Social P2P effort attempts to create a distributed,
privacy-enhanced and privacy-enforcing, user-controlled social network.
The goals of the P2P effort include:

* User Control - The user can run their own node on their own machine
with maximal ease of use and maintenance - it shouldn't take a sysadmin
to be social
* Privacy controls are not merely stated, but are enforced by strong
cryptography and time-tested protocols. All user data, including the
social graph, is private by default.
* Transparent developer access to other social networking systems,
including OStatus - the modular transport/translation system of the P2P
GNU Social will ensure that from the point of view of the end-user and
developer, there is only One Big Network.
* Modularity - Components in the node stack should be separated such
that it is simple to add and remove components. A full, working GNU
Social P2P node will be composed of several different individual
programs, and several different user interfaces. A strong client-side
API should enable developers to integrate P2P GNU Social into all
relevant existing desktop applications. Some of you may remember this
design from the document I posted to this list some months ago[1].
* Composition - Whenever possible, P2P GNU Social will borrow/loot from
existing Free protocols and implementations, though all code written by
us will be licensed under the AGPL.

To learn more about the P2P GNU Social design and structure, visit
<http://groups.fsf.org/wiki/Group:GNU_Social/P2P>. Currently, we have a
prototype for the GNU Social "core", written in Java, hosted on
Gitorious here: <http://gitorious.org/social-p2p/core>. We also have our
own mailing list at <http://lists.gnu.org/mailman/listinfo/social-p2p>
and an IRC channel at <irc://irc.freenode.net/social-p2p>.

We need people to help make this system a reality, by hacking on it and
fleshing out the protocol. Some things that people could get started
with include transport layers or translators for pre-existing networks,
and building user interfaces, ranging from a basic prototype to
integration with existing "social desktop" initiatives and mobile
devices.

We'd like to emphasize that this is **NOT** a fork of the mainline GNU
Social. StatusNet GNU Social and P2P GNU Social fulfill different niches
in the social networking space and should interoperate fully. If you
have to choose on one implementation to work on, it's probably better
for you to work on StatusNet GNU Social - there's more maturity and
it'll be possible to create free social networking systems faster. We
expect that P2P GNU Social will be more of a "research" effort - a
vanguard into privacy-enhanced social networking - which other social
networking systems, including and especially StatusNet GNU Social, will
be able to learn and build from. We have signed copyright assignment
papers with the FSF and expect contributors to do so as well.

We hope that many of the questions people have about how the network
works and how it guarantees privacy can be answered by our design
documents on groups.fsf.org, but please feel free to ask further
questions.

[1] http://groups.fsf.org/wiki/Group:GNU_Social/P2P/Node_Architecture
_______________________________________________
foaf-dev mailing list
foaf-dev@...
http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Peter Williams | 9 Jul 2010 17:45
Favicon

Re: [foaf-dev] Fwd: [Social-discuss] Announcing P2P GNU Social

It is interesting, if only because of the phrase "strong guarantees" about ...

There are two indirections ( guarantor  of x, and issuer of strength recommendation about the guarantor).

It will however use time tested (security) protocols - which have (ssl excepted) not done that well on
designing solutions on the topics underlying such assurance engineering problems.

On Jul 9, 2010, at 4:28 AM, Dan Brickley <danbri@...> wrote:

> Another interesting project! and apparently some code already...
> 
> Dan
> 
> 
> ---------- Forwarded message ----------
> From: Ted Smith <teddks@...>
> Date: Fri, Jul 9, 2010 at 1:21 PM
> Subject: [Social-discuss] Announcing P2P GNU Social
> To: social-discuss <social-discuss@...>, social <social@...>
> 
> 
> For the past few weeks, Miron Cuperman and I have been thinking about
> how to do social networking in a p2p and privacy-enhanced way. We've
> come up with some code and documents that describe a distributed social
> networking system that is able to make and enforce strong guarantees
> about user privacy while still providing usability in the same vein as
> traditional, centralized or hub-and-spoke services. We've collected this
> into an effort to build a P2P GNU Social.
> 
> The GNU Social P2P effort attempts to create a distributed,
> privacy-enhanced and privacy-enforcing, user-controlled social network.
> The goals of the P2P effort include:
> 
> * User Control - The user can run their own node on their own machine
> with maximal ease of use and maintenance - it shouldn't take a sysadmin
> to be social
> * Privacy controls are not merely stated, but are enforced by strong
> cryptography and time-tested protocols. All user data, including the
> social graph, is private by default.
> * Transparent developer access to other social networking systems,
> including OStatus - the modular transport/translation system of the P2P
> GNU Social will ensure that from the point of view of the end-user and
> developer, there is only One Big Network.
> * Modularity - Components in the node stack should be separated such
> that it is simple to add and remove components. A full, working GNU
> Social P2P node will be composed of several different individual
> programs, and several different user interfaces. A strong client-side
> API should enable developers to integrate P2P GNU Social into all
> relevant existing desktop applications. Some of you may remember this
> design from the document I posted to this list some months ago[1].
> * Composition - Whenever possible, P2P GNU Social will borrow/loot from
> existing Free protocols and implementations, though all code written by
> us will be licensed under the AGPL.
> 
> To learn more about the P2P GNU Social design and structure, visit
> <http://groups.fsf.org/wiki/Group:GNU_Social/P2P>. Currently, we have a
> prototype for the GNU Social "core", written in Java, hosted on
> Gitorious here: <http://gitorious.org/social-p2p/core>. We also have our
> own mailing list at <http://lists.gnu.org/mailman/listinfo/social-p2p>
> and an IRC channel at <irc://irc.freenode.net/social-p2p>.
> 
> We need people to help make this system a reality, by hacking on it and
> fleshing out the protocol. Some things that people could get started
> with include transport layers or translators for pre-existing networks,
> and building user interfaces, ranging from a basic prototype to
> integration with existing "social desktop" initiatives and mobile
> devices.
> 
> We'd like to emphasize that this is **NOT** a fork of the mainline GNU
> Social. StatusNet GNU Social and P2P GNU Social fulfill different niches
> in the social networking space and should interoperate fully. If you
> have to choose on one implementation to work on, it's probably better
> for you to work on StatusNet GNU Social - there's more maturity and
> it'll be possible to create free social networking systems faster. We
> expect that P2P GNU Social will be more of a "research" effort - a
> vanguard into privacy-enhanced social networking - which other social
> networking systems, including and especially StatusNet GNU Social, will
> be able to learn and build from. We have signed copyright assignment
> papers with the FSF and expect contributors to do so as well.
> 
> We hope that many of the questions people have about how the network
> works and how it guarantees privacy can be answered by our design
> documents on groups.fsf.org, but please feel free to ask further
> questions.
> 
> [1] http://groups.fsf.org/wiki/Group:GNU_Social/P2P/Node_Architecture
> <signature.asc>
> _______________________________________________
> foaf-dev mailing list
> foaf-dev@...
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Alexander Garcia Castro | 11 Jul 2010 21:50
Picon

[foaf-dev] Natasha Noy and Peter Yim keynote speakers at SERES (ISWC)

--
Alexander Garcia
http://www.alexandergarcia.name/
http://www.usefilm.com/photographer/75943.html
http://www.linkedin.com/in/alexgarciac
Postal address:
Alexander Garcia, Tel.: +49 421 218 64211
Universität Bremen
Enrique-Schmidt-Str. 5
D-28359 Bremen

_______________________________________________
foaf-dev mailing list
foaf-dev@...
http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Antoine Zimmermann | 16 Jul 2010 13:16

[foaf-dev] FOAF DL

Dear all,

I know that the compatibility of FOAF with OWL DL has been discussed a 
lot in the past (and still sometimes surfaces again).  However, I'm 
wondering, would it be reasonable to provide a DL version of FOAF in 
complement of the official FOAF ontology?
More generally, wouldn't it be reasonable to provide alternative 
versions of an ontology?  Think of XHTML: there are three different XML 
Schemas for XHTML [1].  One could imagine alternative versions like FOAF 
(Full), FOAF-DL, FOAF-lite...

Anyway, I did it: I've made a FOAF-DL ontology which modifies the FOAF 
ontology such that (1) it is in OWL 2 DL and (2) it maximally preserves 
inferences of the original FOAF ontology [2].

Interestingly, FOAF-DL is an OWL 2 RL ontology (in a nutshell, OWL 2 RL 
is a subset of OWL 2 DL with low computational complexity and that is 
compatible with rule-based inference engine).

You may notice that there are strange annotation properties for this 
ontology:

<owl:Ontology rdf:about="http://purl.org/az/foaf#">
   ...
   <yoda:preferredVersion rdf:resource="http://xmlns.com/foaf/0.1/"/>
   ...
</owl:Ontology>

The Yoda vocabulary [3] is used to relate alternative versions of an 
ontology. Here, it is said that there is a preferred version, which is 
the official FOAF ontology.

Critiques to any of the previous comments are welcome.

[1] http://www.w3.org/TR/xhtml1-schema/#schemas
[2] The FOAF-DL ontology. http://purl.org/az/foaf
[3] Yoda: A Vocabulary for Linking Alternative Specifications of a 
Vocabulary. http://purl.org/NET/yoda

Regards,
--

-- 
Antoine Zimmermann
Post-doctoral researcher at:
Digital Enterprise Research Institute
National University of Ireland, Galway
IDA Business Park
Lower Dangan
Galway, Ireland
antoine.zimmermann@...
http://vmgal34.deri.ie/~antzim/
Antoine Zimmermann | 16 Jul 2010 17:17

Re: [foaf-dev] FOAF DL

Beware, technical stuff follows.

Le 16/07/2010 13:07, Dave Reynolds a écrit :
> Looks interesting.
>
> In the description you say "(1) foaf:mbox_sha1sum, foaf:jabberID,
> foaf:aimChatID, foaf:icqChatID, foaf:yahooChatID and foaf:msnChatID are
> not owl:InverseFunctionalProperties anymore; instead, they are defined
> as owl:Keys for foaf:Agents, which is practically the same"
>
> I agree that making them owl:Keys is the only option for DL but the
> comment "practically the same" is maybe overstating it.
>
> My understanding was that the semantics of Keys [1] only applies to
> named individuals and so isn't effective on anonymous individuals (which
> is a common use case in FOAF). Is that correct?

Yes, you are correct.

Here, I made a simplifying short cut but saying "practically the same". 
In most cases, a blank node can be simply considered as a named 
individual, using the blank node ID (regardless of whether it is 
specified in the serialisation or internally represented) as a "name" 
for the individual.
In this case, the un-named individual are only those that exists because 
of inferences but which have no identifier at all (for instance, when 
using the OWL construct "owl:someValueFrom".

Such shortcuts are practically used in reasoners to deduce things about 
blank nodes in the same way they deduce things about URIs.

Using this approach on the following data:

foaf:yahooChatID a owl:DatatypeProperty ;
                  rdfs:domain foaf:Agent .
foaf:Agent owl:hasKey ( foaf:yahooChatID ).
_:bnode1 foaf:yahooChatID "xyz" .
_:bnode2 foaf:yahooChatID "xyz" .

one can infer:

_:bnode1 owl:sameAs _:bnode2 .

When the serialisation does not specify a name for a blank node, their 
is still an internal name somewhere.  For instance:

[ a :Person ] foaf:yahooChatID "xyz" ;
    foaf:firstName "John" .
[ a :Person ] foaf:yahooChatID "xyz" ;
    foaf:lastName "Doe" .

allows one to infer that there is one person with first name "John" and 
last name "Doe" (but its local identifier is only known to the reasoner).

An example where the inference would not hold is as follows:

:chatID a owl:DatatypeProperty ;
         rdfs:domain :Agent .
:Agent owl:hasKey ( :chatID ).
:hasFather a owl:ObjectProperty, owl:FunctionalProperty .
:john :chatId "xyz" .
:bob a [ owl:Restriction ;
          owl:onProperty :hasFather ;
          owl:allValuesFrom [ a owl:Restriction;
                              owl:onProperty :chatId;
                              owl:hasValue "xyz" ]
        ] .

from this, we cannot conclude that John is the father of Bob, although 
Bob has a father (un-named) whose :chatId is exactly the same as John.
If :chatId was inverse functional, we could conclude it. However, I said 
"practically the same" because this case is unlikely to occur in practice.

Hope it's clear enough. For the specs for keys, see [1,2,3].

[1] OWL 2 Web Ontology Language - Structural Specification and 
Functional-Style Syntax, Sect.9.5 Keys. 
http://www.w3.org/TR/owl2-syntax/#Keys
[2] OWL 2 Web Ontology Language - New Features and Rationale, Sect.2.2.6 
F9: Keys. http://www.w3.org/TR/owl2-new-features/#F9:_Keys
[3] OWL 2 Web Ontology Language - Direct Semantics, Sect.2.3.5 Keys. 
http://www.w3.org/TR/owl2-semantics/#Keys

Regards,
>
> Dave
>
> [1] http://www.w3.org/TR/owl2-direct-semantics/#Keys
>
> On Fri, 2010-07-16 at 12:16 +0100, Antoine Zimmermann wrote:
>> Dear all,
>>
>>
>> I know that the compatibility of FOAF with OWL DL has been discussed a
>> lot in the past (and still sometimes surfaces again).  However, I'm
>> wondering, would it be reasonable to provide a DL version of FOAF in
>> complement of the official FOAF ontology?
>> More generally, wouldn't it be reasonable to provide alternative
>> versions of an ontology?  Think of XHTML: there are three different XML
>> Schemas for XHTML [1].  One could imagine alternative versions like FOAF
>> (Full), FOAF-DL, FOAF-lite...
>>
>> Anyway, I did it: I've made a FOAF-DL ontology which modifies the FOAF
>> ontology such that (1) it is in OWL 2 DL and (2) it maximally preserves
>> inferences of the original FOAF ontology [2].
>>
>> Interestingly, FOAF-DL is an OWL 2 RL ontology (in a nutshell, OWL 2 RL
>> is a subset of OWL 2 DL with low computational complexity and that is
>> compatible with rule-based inference engine).
>>
>> You may notice that there are strange annotation properties for this
>> ontology:
>>
>> <owl:Ontology rdf:about="http://purl.org/az/foaf#">
>>     ...
>>     <yoda:preferredVersion rdf:resource="http://xmlns.com/foaf/0.1/"/>
>>     ...
>> </owl:Ontology>
>>
>> The Yoda vocabulary [3] is used to relate alternative versions of an
>> ontology. Here, it is said that there is a preferred version, which is
>> the official FOAF ontology.
>>
>> Critiques to any of the previous comments are welcome.
>>
>>
>> [1] http://www.w3.org/TR/xhtml1-schema/#schemas
>> [2] The FOAF-DL ontology. http://purl.org/az/foaf
>> [3] Yoda: A Vocabulary for Linking Alternative Specifications of a
>> Vocabulary. http://purl.org/NET/yoda
>>
>>
>> Regards,
>
>

--

-- 
Antoine Zimmermann
Post-doctoral researcher at:
Digital Enterprise Research Institute
National University of Ireland, Galway
IDA Business Park
Lower Dangan
Galway, Ireland
antoine.zimmermann <at> deri.org
http://vmgal34.deri.ie/~antzim/
_______________________________________________
foaf-dev mailing list
foaf-dev <at> lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-dev
Damian Steer | 16 Jul 2010 17:54
Picon

Re: [foaf-dev] FOAF DL

On 16/07/10 12:16, Antoine Zimmermann wrote:
> Dear all,
> 
> 
> I know that the compatibility of FOAF with OWL DL has been discussed a
> lot in the past (and still sometimes surfaces again).  However, I'm
> wondering, would it be reasonable to provide a DL version of FOAF in
> complement of the official FOAF ontology?

The problem in the past (as I recall) has been discoverability. If you
could get DL tools to  _import_ fallbacks to your variant that would
help. Yoda seems like it's in that direction at first glance.

Damian
Vasiliy Faronov | 20 Jul 2010 14:23
Picon
Gravatar

[foaf-dev] A few corrections

Hi,

Here are a few small corrections to the FOAF spec.

In the list of terms from the "Documents and Images" category, there is
a link pointing to "primaryTopicOf". The link doesn't work because the
term is actually "isPrimaryTopicOf".

The description of foaf:PersonalProfileDocument includes the following
sentence:
  "Anything that is a Person and that is the maker of some Document 
   will be the primaryTopic of that Document."
Apparently this is a mistake, and "PersonalProfileDocument" should be
substituted for "Document" in this sentence.

The list of terms of the "Personal Info" category should include
foaf:status. Similarly, foaf:openid should be added either to the
"Personal Info" list or the "Online Accounts / IM" one.

--

-- 
Vasiliy Faronov
Dan Brickley | 20 Jul 2010 15:22

Re: [foaf-dev] A few corrections

On Tue, Jul 20, 2010 at 2:23 PM, Vasiliy Faronov <vfaronov@...> wrote:
> Hi,
>
> Here are a few small corrections to the FOAF spec.
>
> In the list of terms from the "Documents and Images" category, there is
> a link pointing to "primaryTopicOf". The link doesn't work because the
> term is actually "isPrimaryTopicOf".

Thanks! I'm sure I fixed this once already but it got reverted
somehow. Fixed in SVN now:

 svn commit -m "fixed bad link to [is]primaryTopicOf" template.html
Committed revision 1377.

> The description of foaf:PersonalProfileDocument includes the following
> sentence:
>  "Anything that is a Person and that is the maker of some Document
>   will be the primaryTopic of that Document."
> Apparently this is a mistake, and "PersonalProfileDocument" should be
> substituted for "Document" in this sentence.

Thanks, fixed in SVN now:

svn commit -m "We had Document instead of PersonalProfileDocument."
PersonalProfileDocument.en
Sending        PersonalProfileDocument.en
Transmitting file data .
Committed revision 1378.

> The list of terms of the "Personal Info" category should include
> foaf:status. Similarly, foaf:openid should be added either to the
> "Personal Info" list or the "Online Accounts / IM" one.

I'll hold on this for now, as I want to revisit the category lists for
next publication. But thanks, noted!

The other changes will show up next time the spec is regenerated.
Thanks for the careful read through...

cheers,

Dan
> --
> Vasiliy Faronov
>
>
> _______________________________________________
> foaf-dev mailing list
> foaf-dev@...
> http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>
Stéphane Corlosquet | 23 Jul 2010 15:26
Picon
Gravatar

Re: [foaf-dev] [pedantic-web] RE: [StatusNet-dev] StatusNet Void FOAF mbox_sha1sum values

Aidan,


On Tue, May 18, 2010 at 6:33 PM, Hogan, Aidan <aidan.hogan-KpECg1RYOug@public.gmane.org> wrote:
> <at> FOAF-DEV. Would you consider adding a property
> 'foaf:accountProfilePage' to FOAF? Or would you recommend a different
> property for the following usage:
>
> <OnlineAccount rdf:about="http://identi.ca/user/269#acct">
>     <accountServiceHomepage
> rdf:resource="http://identi.ca/"></accountServiceHomepage>
>     <accountName>segphault</accountName>
>     ***<accountProfilePage
> rdf:resource="http://identi.ca/segphault"></accountProfilePage>***
>     <sioc:account_of
> rdf:resource="http://identi.ca/user/269"></sioc:account_of>
>     <sioc:follows
> rdf:resource="http://identi.ca/user/1020#acct"></sioc:follows>
> </OnlineAccount>

Just to follow up on this, after discussion with Dan (who will hopefully correct me if I'm wrong) he would recommend use of the 'accountProfilePage' URI to actually identify the OnlineAccount, à la:

<OnlineAccount rdf:about="http://identi.ca/segphault">
    <accountServiceHomepage
 rdf:resource="http://identi.ca/"></accountServiceHomepage>
    <accountName>segphault</accountName>
    <sioc:account_of
 rdf:resource="http://identi.ca/user/269"></sioc:account_of>
    <sioc:follows rdf:resource="http://identi.ca/user/1020#acct"></sioc:follows>
</OnlineAccount>

From my own perspective, I agree that this is perhaps the simplest solution, giving a very succinct and natural means of using foaf:account/foaf:OnlineAccount (esp. in RDFa), and more generally removing the headache of creating a new URI for an OnlineAccount.

So you'd basically replace *all* the http://identi.ca/user/1020#acct URIs with their http://identi.ca/segphault counterpart, is that right? I think that would make the RDF model clearer, leaving out the #acct URIs. (in this case the last URI in your snippet above would be http://identi.ca/whataboutbob).
 

Perhaps one thing that slightly concerns me is when SIOC is considered... In the above usage, an foaf:OnlineAccount could be informally considered as a subclass of foaf:Document. Since sioc:UserAccount is a subclass of foaf:OnlineAccount, this means that you could have statements such as:

<profileDocA> sioc:follows <profileDocB> .

...which seems to me a little bit strange. Again, this is only when including SIOC into the frame.

That's what we do in Drupal 7: each user profile page is explicitly typed sioc:UserAccount out of simplicity. (this decision was discussed with Danbri) See a random example taken from the wild: http://bryanhouse.drupalgardens.com/users/bryan-house. Afaik, there is no formal disjointness between sioc:UserAccount/foaf:OnlineAccount and foaf:Document. (note btw that the user profile page is not explicitly typed as foaf:Document).

Steph.
_______________________________________________
foaf-dev mailing list
foaf-dev@...
http://lists.foaf-project.org/mailman/listinfo/foaf-dev

Gmane