Two weeks of SIOC wishes

12 views
Skip to first unread message

Uldis Bojars

unread,
Apr 17, 2009, 12:27:56 PM4/17/09
to SIOC-Dev
Hi,

SIOC team has come up with an idea for "2 weeks of SIOC wishes":

You are encouraged to respond by writing here / on your blog / twitter
/ [you name it] about your wishes for SIOC:
- what new applications would you like to see?
- what features / bugfixes are you looking for in existing applications?
- new ontology terms or integration with other ontologies?
- [better] explanations of SIOC terms or answers to puzzling questions needed?
- ...

Let's brainstorm a bit so that we get a feel of what the community wants.

The activity runs from today until the end of April. Will summarize
received ideas after that.

Wiki is a good place to record ideas: http://wiki.sioc-project.org/w/WishList

Uldis

Uldis Bojars

unread,
Apr 21, 2009, 9:07:44 AM4/21/09
to SIOC-Dev
> SIOC team has come up with an idea for "2 weeks of SIOC wishes":

Looks like everyone used the wiki [1] to record their wishes (which is
why it kept quiet here).

Thanks to everyone who contributed. If there are still some things you
want to mention, feel free to do so. The wishlist may also be used for
describing application or ontology ideas which you have wanted to do
but never got time for it. Perhaps someone else likes the idea and
implements it.

[1] http://wiki.sioc-project.org/w/WishList

One source of ideas is this mailing list. There must be things that
were discussed here, which we may want to revisit.

It would be good if SIOC-Dev mailing list was available as linked data
or as a downloadable archive. Do you have ideas how to do this?
Perhaps someone already has such an archive? (unfortunately Google
Groups does not provide an API)

Uldis

Uldis Bojars

unread,
Apr 22, 2009, 11:51:23 AM4/22/09
to SIOC-Dev
The most requested feature on [1] (with 3 votes) is renaming sioc:User
to sioc:UserAccount.

[1] http://wiki.sioc-project.org/index.php/WishList#Two_weeks_of_SIOC_wishes

Uldis

Matthias Samwald

unread,
Apr 23, 2009, 4:40:46 AM4/23/09
to SIOC-Dev
... and so we change the URI of an important class in the schema,
losing backwards compatibility? Maybe only the rdfs:label should be
changed, and not the URI? After all, the semantics did not change, you
only want to clarify the semantics.

This is an example of how the drawbacks of human-readable URIs (of
course, they have practical advantages, too).

-- Matthias

Simon Reinhardt

unread,
Apr 23, 2009, 7:24:17 AM4/23/09
to SIOC-Dev
On Apr 23, 9:40 am, Matthias Samwald <samw...@gmx.at> wrote:
> ... and so we change the URI of an important class in the schema,
> losing backwards compatibility? Maybe only the rdfs:label should be
> changed, and not the URI? After all, the semantics did not change, you
> only want to clarify the semantics.

The idea is to make sioc:User a owl:DeprecatedClass and make it the
owl:equivalentClass of sioc:UserAccount, as in [1].
This will still allow people to user the former one. Uldis said
something along the lines of: most people that export/use data in SIOC
today are in more or less close contact with the SIOC group and it's a
small number of users anyway. So they will probably all be approached
to change it in their data, the impact shouldn't be too big then.

Regards,
Simon

[1] http://www.w3.org/TR/owl-ref/#Deprecation

Alexandre Passant

unread,
Apr 23, 2009, 7:38:42 AM4/23/09
to sioc...@googlegroups.com
Hi,

Le 23 avr. 09 à 12:24, Simon Reinhardt a écrit :
Let's keep in mind things like updating the Yahoo! SearchMonkey doc,
people using SIOC in organisations, adapting / rewriting SPARQL
queries in existing applications (or reasoning over
owl:equivalentClass, etc.)
I'm not confident with renaming a URI and I think that it can be
clarified in the label / description.

Alex.


>
>
> Regards,
> Simon
>
> [1] http://www.w3.org/TR/owl-ref/#Deprecation
> >

--
Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .

Simon Reinhardt

unread,
Apr 23, 2009, 8:52:34 AM4/23/09
to SIOC-Dev


On Apr 23, 12:38 pm, Alexandre Passant <alexandre.pass...@deri.org>
wrote:
> Le 23 avr. 09 à 12:24, Simon Reinhardt a écrit :
> > The idea is to make sioc:User a owl:DeprecatedClass and make it the
> > owl:equivalentClass of sioc:UserAccount, as in [1].
> > This will still allow people to user the former one. Uldis said
> > something along the lines of: most people that export/use data in SIOC
> > today are in more or less close contact with the SIOC group and it's a
> > small number of users anyway. So they will probably all be approached
> > to change it in their data, the impact shouldn't be too big then.
>
> Let's keep in mind things like updating the Yahoo! SearchMonkey doc,  
> people using SIOC in organisations, adapting / rewriting SPARQL  
> queries in existing applications (or reasoning over  
> owl:equivalentClass, etc.)
> I'm not confident with renaming a URI and I think that it can be  
> clarified in the label / description.

Well, I wouldn't see this so much as a renaming but rather as
introducing a new URI. Nothing will break if you keep using the old
URI, you will still be able to dereference it (though I'm not sure how
many applications actually do that). You're right though, there is a
problem when an exporting / data producing application changes it and
consuming applications depending on it don't get updated.

Regards,
Simon

Olivier GENDRIN

unread,
Apr 23, 2009, 9:44:24 AM4/23/09
to sioc...@googlegroups.com
On Thu, Apr 23, 2009 at 10:40 AM, Matthias Samwald <sam...@gmx.at> wrote:
> ... and so we change the URI of an important class in the schema,
> losing backwards compatibility? Maybe only the rdfs:label should be
> changed, and not the URI? After all, the semantics did not change, you
> only want to clarify the semantics.
>
> This is an example of how the drawbacks of human-readable URIs (of
> course, they have practical advantages, too).

I'll perhaps make obvious how lame I'm am at understanding RDF, but
there is not RDF equivalent of http 301 Moved Permanently status?

--
Olivier G.
http://twitter.com/lespacedunmatin
http://www.lespacedunmatin.info/blog/

Daniel E. Renfer

unread,
Apr 23, 2009, 10:45:08 AM4/23/09
to sioc...@googlegroups.com
Simon Reinhardt <simon.r...@gmail.com> writes:

While UserAccount more clearly explains what is being represented, User
is still not a bad name.

A large portion of SIOC is being generated automatically, so fixing
thousands of pages in an application would most likely require only a
few changes, but I'm willing to bet that there is quite a bit of
hand-made SIOC that wouldn't get updated.

If everyone is in favor of it, I don't have a problem. I'm just
wondering how many applications will get broken because they're not
doing full infrencing on the data.

Daniel E. Renfer
xri: @id*duck

Simon Reinhardt

unread,
Apr 23, 2009, 5:44:26 PM4/23/09
to SIOC-Dev
On Apr 23, 3:45 pm, d...@kronkltd.net (Daniel E. Renfer) wrote:
> While UserAccount more clearly explains what is being represented, User
> is still not a bad name.

I have to say I do find it a bad name because a user is a person; it's
more like a role but it still describes a person, not an account. And
the problem here is not so much a simple clarification of the
definition - you wouldn't have to change a URI for that. The problem
is that the confusion already happens. A prominent example is
identi.ca/laconi.ca [1] and I've seen other people easily confuse them
as well. For now we can address them all individually and let them fix
it but as adoption grows you won't be able to track anymore who uses
SIOC. And how will people find out they're doing something wrong then?
Where's the feedback? Will they look at the spec and pick the terms
they think are correct or will they copy deployed patterns?

If it was me I would get rid of sioc:User altogether and just use
foaf:OnlineAccount. :-)

Regards,
Simon

[1] http://laconi.ca/trac/ticket/1367

Uldis Bojars

unread,
Apr 23, 2009, 6:54:14 PM4/23/09
to SIOC-Dev
On Apr 23, 1:52 pm, Simon Reinhardt <simon.reinha...@gmail.com> wrote:
> > Let's keep in mind things like updating the Yahoo! SearchMonkey doc,  
> > people using SIOC in organisations, adapting / rewriting SPARQL  
> > queries in existing applications (or reasoning over  
>
> Well, I wouldn't see this so much as a renaming but rather as
> introducing a new URI. Nothing will break if you keep using the old
> URI, you will still be able to dereference it (though I'm not sure how

Indeed. We can keep sioc:User around for a while (as a
DeprecatedProperty).

> many applications actually do that). You're right though, there is a
> problem when an exporting / data producing application changes it and
> consuming applications depending on it don't get updated.

As Daniel wrote in one of the subsequent messages, most SIOC is
generated automatically and implementing ontology changes would
require just a few application changes.

Re. consumer applications - let's analyse what consumer applications
would feel the impact. That is, what applications depend specifically
on sioc:User and use data created by SIOC exporters which we will
change. Could you list these applications here?

Alex is correct that changes will also need to be propagated to other
locations such as SearchMonkey documentation. But Peter Mika was one
of the first to propose this change and perhaps he can make sure that
relevant docs get changed?

Uldis

Uldis Bojars

unread,
Apr 23, 2009, 6:57:41 PM4/23/09
to SIOC-Dev

On Apr 23, 10:44 pm, Simon Reinhardt <simon.reinha...@gmail.com>
wrote:
> I have to say I do find it a bad name because a user is a person; it's
> more like a role but it still describes a person, not an account. And
> the problem here is not so much a simple clarification of the
> definition - you wouldn't have to change a URI for that. The problem
> is that the confusion already happens. A prominent example is
> identi.ca/laconi.ca [1] and I've seen other people easily confuse them
> as well. For now we can address them all individually and let them fix

A wiki page about issues with SIOC data on identi.ca/laconi.ca (that
Simon just mentioned):

http://wiki.sioc-project.org/index.php/IdenticaSiocData

Uldis

Richard Cyganiak

unread,
Apr 24, 2009, 7:58:45 AM4/24/09
to sioc...@googlegroups.com

On 23 Apr 2009, at 23:54, Uldis Bojars wrote:
> Re. consumer applications - let's analyse what consumer applications
> would feel the impact. That is, what applications depend specifically
> on sioc:User and use data created by SIOC exporters which we will
> change. Could you list these applications here?

I would hope that most if not all implementers of SIOC consumers are
subscribed to this list, and hence will be aware of the change.

It's probably a good idea to send a very loud and clear warning here
on the list before starting any changes, and give clients some time in
which they can adapt their apps to accept both sioc:User and
sioc:UserAccount.

Best,
Richard

John Breslin

unread,
May 13, 2009, 11:03:11 AM5/13/09
to SIOC-Dev
I'm a little bit worried about the amount of effort that will be
required to get all User's updated to UserAccount's although I agree
with the idea of the rename in general.

We can probably track down most of them (the majority) - but I'd like
to hear about any other potential side effects before we change it.

Uldis Bojars

unread,
May 13, 2009, 2:12:04 PM5/13/09
to SIOC-Dev
There have been no replies from authors of SIOC exporters expressing
concern about this change. If Richard's assumption is correct and most
(if not all) implementers of SIOC are reading this list, then we could
conclude developers of SIOC-consuming applications are not concerned
with this change (or they would speak up).

However, let's not rely on that and make a list of SIOC applications
(both consumers and producers of SIOC) that would be affected by such
a change. Then we can contact all the developers and discuss the
change. Use this wiki page to create the list:

http://wiki.sioc-project.org/index.php/FeatureRequests/SiocUserAccount#Impact

Most applications can be easily updated. Also, many RDF applications
are generic and would not feel any impact (unless they do queries or
some other processing that uses sioc:User). A class of applications
that might be problematic are industrial / research projects which may
have finished or may be unwilling to change finished applications (on
the other hand, this is a simple search and replace task).

John, you mentioned other potential side effects. What other side
effects should we be aware of?

Uldis

Breslin, John

unread,
May 20, 2009, 5:05:53 AM5/20/09
to sioc...@googlegroups.com
An alternative is to recommend usage of foaf:OnlineAccount as Simon hinted...


--
John Breslin
NUI Galway
http://www.johnbreslin.org/
john.b...@nuigalway.ie

Dan Brickley

unread,
May 20, 2009, 6:34:23 AM5/20/09
to sioc...@googlegroups.com
On 20/5/09 11:05, Breslin, John wrote:
> An alternative is to recommend usage of foaf:OnlineAccount as Simon hinted...

If any clarifications/changes to definition of foaf:OnlineAccount would
help here, let me know.

cheers

Dan

Uldis Bojars

unread,
May 20, 2009, 7:13:53 AM5/20/09
to sioc...@googlegroups.com
On Wed, May 20, 2009 at 11:34 AM, Dan Brickley <dan...@danbri.org> wrote:
> On 20/5/09 11:05, Breslin, John wrote:
>> An alternative is to recommend usage of foaf:OnlineAccount as Simon hinted...

Is that a better alternative, though?

For one thing it won't solve the problem that we were discussing in
this thread - the change still impacts applications working with
SIOC.

> If any clarifications/changes to definition of foaf:OnlineAccount would
> help here, let me know.

Regardless of changes to sioc:User, it would be good to "sync" its
definition with foaf:OnlineAccount. Currently sioc:User subclasses it
but does not really use properties that are associated with
foaf:OnlineAccount.

Good to know that the definition of foaf:OnlineAccount can be adjusted
if necessary.

All, any suggestions how to proceed?

Uldis

Dan Brickley

unread,
May 20, 2009, 7:24:49 AM5/20/09
to sioc...@googlegroups.com, foaf-dev Friend of a
+cc: foaf-dev

For me lately, I think the core idea of an OnlineAccount is that it is
something that exemplifies shared control: between some user and some
service provider. This has several aspects. Data sourced from the
account is sometimes from the user, sometimes from the service provider.
So I have been looking at ways of indicating which parts have been
supplied or checked by the provider (eg. email verified, openid
verified, or stuff like trust rankings). Also typically there are ways
in which a user can demonstrate control over some account. Openid is the
obvious one here, but email verification codes, text messages etc are
also used. Finally, I am thinking that the machinery familiar from vcard
where we have "home" "work" etc flags for phone numbers, fax etc should
be applicable to anything that is an OnlineAccount. Does this fit with
SIOC perspective? Why can't I say "this is my Work Blog, my Home IM, my
work phone number, my home bookmarks, my work activity stream, etc?

Dan

Uldis Bojars

unread,
May 20, 2009, 8:13:16 AM5/20/09
to sioc...@googlegroups.com
On Wed, May 13, 2009 at 4:03 PM, John Breslin <john.b...@nuigalway.ie> wrote:

> We can probably track down most of them (the majority) - but I'd like
> to hear about any other potential side effects before we change it.

Another side effect would be that the ontology will have changed but
we can not change published papers that talk about SIOC and mention
sioc:User. But, since the proposal is to deprecate sioc:User (with a
note pointing to its replacement) and not to delete it, this is not a
big issue.

Uldis

Reply all
Reply to author
Forward
0 new messages