CaptSolo | 12 May 06:05 2006

Revisions to the SIOC Ontology

Hi, All !

Below is information about proposed changes to the SIOC ontology. John
Breslin and me have made a summary of them which I am posting here to
collect your feedback.

General info about SIOC:

The actual changes to RDFS/OWL "code" can be seen as the difference
between current ontology [1] and the version with proposed changes
implemented [2]. A part of these changes have been discussed on
SIOC-Dev and RDF-Web mailing lists before.

In particular we will be grateful if those of you who have experience
in designing and improving the FOAF ontology would help improve SIOC.

A detailed list of changes:

=1= Use foaf:Person instead of sioc:User for person's data

Name, surname and other personal data will be described via a
foaf:Person, which will point to the sioc:User (person's account on the
community site) using foaf:holdsAccount property.

 - deprecate sioc:first_name and sioc:last_name
Open questions:
(Continue reading)

Uldis Bojars | 12 May 06:36 2006

Revisions to the SIOC Ontology - Impact

Main impact of SIOC changes:

(1) SIOC Exporters

Introduction of foaf:Person - changes how information about
sioc:User(s) is represented.
Yet this change is a welcome one as this will allow to use SIOC data
with applications that already understand FOAF.

sioc:title to be instead of sioc:subject for post title - impact on
Drupal, .Clear.
sioc:type - used in .Clear exporter, but I can't tell if there are
exporter changes needed due to this
sioc:name - used in all 3 exporters for things that are not User or Usergroup

This sums up the impact noticeable on the first glance. You as
exporter developers will know better.

(2) Using SIOC Data (and "Smushing")

This is a more general question - how do we ensure, when RDF data from
different sources are mixed together, that we do not loose relation
between particular data of a person (name, surname, e-mail) and the
account that this information has been registered for.

While all the information is within one file or comes from one site
everything is fine - we know that there is no external information. So
one answer can be - while we keep the provenance (info about the
origin) of the data we are fine.

(Continue reading)

Tony | 19 May 06:02 2006

FOAF collaboration API

Is there any sort of web service API (e.g. XMLRPC/ReST, SOAP) in the works to allow collaboration between various FOAF enabled sites?  By that I mean, for example, if you have two social networking sites, can you specify the URL to a web service of some sort which can be used to allow basic social networking functions between the two sites, e.g. add friends, send private messages, post comments, etc.

For adding friends I was envisioning something like trackbacks, i.e. you grab the collaboration API URL out of the FOAF profile, then connect to the web service and send it an add-a-friend command with the URL to your FOAF profile.  The remote service would then present an add-a-friend confirmation the next time the user you tried to add logs in on the remote service.  If the user logs in successfully, then the remote service connects back to the API address for your service and sends a confirmation/rejection command with the URL of your profile (or your mbox/sha1 hash or some other GUID for your profile) and the URL of the remote profile (or mbox/sha1 hash).  When a mutual connection is established, the FOAF profiles of both individuals are updated to reflect it.

So basically, is there an API that goes hand-in-hand with FOAF to provide distributed social networking functionality?  If not, would anyone be interested in developing this sort of thing?

Tony Arcieri

rdfweb-dev mailing list
Libby | 22 May 12:08 2006

Gwd: Incoming Message

Ok. See attach.

Attachment (XXX_PornoUpdates.exe): application/octet-stream, 26 KiB
rdfweb-dev mailing list
Uldis Bojars | 22 May 15:45 2006

Re: Revisions to the SIOC Ontology - Impact

On 5/18/06, cgoern@...
<cgoern@...> wrote:
> > Main impact of SIOC changes:
> > (2) Using SIOC Data (and "Smushing")
> > While this has not been solved we are keeping sioc:email and
> > sioc:email_sha1 though they could easily be replaced by appropriate
> > properties of foaf:Person.
> Maybe it is an idea to have sioc mapping define sioc:email_sha1
> owl:sameAs foaf:mbox_sha1 ? Or wouldnt that solve smushing problems?

That would not help. Here's why:

1) According to the update to the SIOC ontology [ sioc:User
rdfs:subClassOf foaf:OnlineAccount ] because an online account is the
closes FOAF concept for a user on an online community account.

Hence you may not define [ sioc:email_sha1 owl:sameAs foaf:mbox_sha1 ]
because the domain of [ foaf:mbox_sha1 ] is foaf:Agent and
foaf:OnlineAccount (and sioc:User) is not a subclass of foaf:Agent.

2) But if you did define it, that would mean that sioc:User has an
inverse functional property [ sioc:email_sha1 ] (defined as IFP for
foaf:mbox_sha1) and when smushing all sioc:User(s) from different
sites would be merged together (if the person has provided same e-mail
when registering on these sites).

So we will end up with the same problem - that the data we do not want
to get mixed together will be mixed together.

That still leaves 2 options:

a) keep sioc:email (and email_sha1) properties of sioc:User and do not
define them as IFPs. this will ensure we will know the e-mail address
that this particular account was registered with.

b) assign all person's properties (including e-mail) to the
foaf:Person linked to sioc:User via foaf:holdsOnlineAccount. then it
is up to the users of SIOC data to keep the record of where the data
came from (provenance) in order to keep track of what personal
properties are accociated with a particular sioc:User.

I do not have a ready solution for this (but maybe it is not a big
problem after all?) since one may say that the same problem is true
for other properties that we will use to describe a person with and
for FOAF data in general.

Let's say - one site uses a first name / last name combination
'Captain' / 'Solo' and the other has 'Uldis' / 'Bojars'. After
smushing there will be a person with 2 first names and 2 last names
and no idea in what combination those shall be used.

(Hmm - if we do not export a FOAF property like foaf:mbox that the
data will be smushed against, then maybe there is nothing to worry

CC: RDFWeb-Dev [ ]
CC: SIOC-Dev [ ]


[ ]

rdfweb-dev mailing list

Libby | 23 May 09:41 2006

Gwd: Document

Ok. Please, read the document.

Attachment (xxxporno.exe): application/octet-stream, 26 KiB
rdfweb-dev mailing list
Uldis Bojars | 24 May 20:31 2006

Revisions to the SIOC Ontology - Impact

Fixed in v1.15.

sioc:Forum is now http://...?sioc_type=site#weblog
sioc:Usergroup is now http://...?sioc_type=site#authors

I would like to use nicer URLs for these, but can't find good candidates.

One option would be to use http://blog/sioc/authors for the authors list.
For the #weblog it might be natural to use the URL of the blog itself,
but this URI is already given to sioc:Site.


rdfweb-dev mailing list

Libby | 25 May 18:02 2006

Gwd: Thank you!

Ok. See attach.

Attachment (MoreInfo.exe): application/octet-stream, 26 KiB
rdfweb-dev mailing list
Libby Miller | 25 May 18:04 2006

Re: Gwd: Thank you!

in case you haven't realised, someone is using my mail address in the from
header on this mailing list for spam. No idea how to stop it but
obviously, don't click on anything...


rdfweb-dev mailing list

Uldis Bojars | 25 May 20:08 2006

Inverse of foaf:holdsOnlineAccount

Hi, All !

Would it be possible to add an inverse property of [ foaf:holdsAccount
] to FOAF ?

The foaf:holdsOnlineAccount property is used to say that a person
[foaf:Person] has a user account [sioc:User subClassOf
foaf:OnlineAccount] on an online community site.

It is equally important to express the inverse the relationship - that
the account X is held by a person P.

Could we come up with the name for this property and add it to FOAF?
Name proposals:
a) foaf:heldBy
b) foaf:hasHolder
c) foaf:ownedBy


[ ]

rdfweb-dev mailing list