SIOC, IRC and events

Hi all,

Having some thoughts this afternoon on how to represent a user
connecting / disconnecting channels on IRC, I thaught a sioc:Event
class might be useful.
More generally, it can help to represent subscription to
sioc:Containers, as IRC join / quit, RSS subscribing, starting
membership in a forum ...

This Event class could be defined in the SIOC core itself, but we may
also reuse (or subclass) existing Event classes from other ontologies
(I didn't look yet, but I think that iCal / music ontology Events may
fit there), and use
- sioc:has_creator
- sioc:has_container
- dcterms:created
- dc:description
to define event property and link it to associated Container / User

More specific event types could be then defined in SIOC core or in
external module, as, JoinEvent / QuitEvent and AwayEvent / BackEvent.
(And even some types specific to the container (as IRCJoinEvent), but
I'm afraid it will lead to a lot of event types, while the 4 first
ones should be enough to describe almost everything, combined with the
sioctypes module to define container type (IRC, Forum ...))

Eg:

a sioct:ChatChannel.

a sioc:JoinEvent ;
sioc:has_container ;
sioc:has_creator ;
dcterms:created "2006-11-03T12:05:00Z"^^xsd:dateTime .

a sioc:QuitEvent ;
sioc:has_container ;
sioc:has_creator ;
dc:description "Leaving" ;
dcterms:created "2006-11-03T12:10:00Z"^^xsd:dateTime .

Any comments ?

Best,

Alex.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

SIOC, IRC and events

Hi Alexandre!

[snip]

>
> This Event class could be defined in the SIOC core itself, but we may
> also reuse (or subclass) existing Event classes from other ontologies
> (I didn't look yet, but I think that iCal / music ontology Events may
> fit there), and use
> - sioc:has_creator
> - sioc:has_container
> - dcterms:created
> - dc:description
> to define event property and link it to associated Container / User
>

Just a small comment: we published last week a documentation draft for
the event ontology we use in MO. It is available there:

http://motools.sf.net/event/

I hope it can indeed provide a good basis for that :-)

According to your examples, it would be something like:

sioc:has_creator rdfs:subPropertyOf event:agent.
sioc:has_container rdfs:subPropertyOf event:factor. ?

Cheers!
y

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

SIOC, IRC and events

Yves Raimond wrote:
> Hi Alexandre!
>
> [snip]
>
>> This Event class could be defined in the SIOC core itself, but we may
>> also reuse (or subclass) existing Event classes from other ontologies
>> (I didn't look yet, but I think that iCal / music ontology Events may
>> fit there), and use
>> - sioc:has_creator
>> - sioc:has_container
>> - dcterms:created
>> - dc:description
>> to define event property and link it to associated Container / User

For referring to/annotating events: wouldn's iCal/RDF be a natural hook?
There is a translator from iCal to RDF at:
http://www.kanzaki.com/courier/ical2rdf
equally related the hCalendar microformat version of iCal:
http://microformats.org/wiki/hcalendar

axel

> Just a small comment: we published last week a documentation draft for
> the event ontology we use in MO. It is available there:
>
> http://motools.sf.net/event/
>
> I hope it can indeed provide a good basis for that :-)
>
> According to your examples, it would be something like:
>
> sioc:has_creator rdfs:subPropertyOf event:agent.
> sioc:has_container rdfs:subPropertyOf event:factor. ?
>
>
> Cheers!
> y
>
> >
>

--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

SIOC, IRC and events

Hi,

I have some experience with designing and implementing online events
which export to RSS, iCalendar and SIOC. In my case I used the
event-module for the SIOC output because it was the only one available
at that time, and it is fairly limited.
http://purl.org/rss/1.0/modules/event

I don't think using an iCalendar ontology is a good idea for events.
iCalendar is a format intended to be interchangable between calendering
applications, not to describe events in the best way possible. A great
number of the properties of iCalendar belong in different ontologies. It
supports todo's and alarms and other things that have absolutely nothing
to do with events. Not to mention the fact that it allows for custom
extensions to be made that are undefined potentially making a perfectly
valid iCalendar file impossible to translate.

Using a new ontology will provide more flexibility and simplicity while
it will still be possible to automatically transform it to iCalendar for
backward compatiblity.

The draft at http://motools.sf.net/event/ looks good, but it definetely
needs a way to define the status of the event, since the existence of a
future event is still uncertain until it has actually happened.
iCalendar allows for an event status to be set to
confirmed, tentative, cancelled which is very useful. Through
experience I found out that another status in the likes of 'sold out'
or 'booked full' would also be very useful.

Greetings,

John

Axel Polleres wrote:
> Yves Raimond wrote:
> > Hi Alexandre!
> >
> > [snip]
> >
> >> This Event class could be defined in the SIOC core itself, but we
> >> may also reuse (or subclass) existing Event classes from other
> >> ontologies (I didn't look yet, but I think that iCal / music
> >> ontology Events may fit there), and use - sioc:has_creator -
> >> sioc:has_container - dcterms:created - dc:description to define
> >> event property and link it to associated Container / User
>
>
> For referring to/annotating events: wouldn's iCal/RDF be a natural
> hook? There is a translator from iCal to RDF at:
> http://www.kanzaki.com/courier/ical2rdf equally related the hCalendar
> microformat version of iCal: http://microformats.org/wiki/hcalendar
>
> axel
>
>
> > Just a small comment: we published last week a documentation draft
> > for the event ontology we use in MO. It is available there:
> >
> > http://motools.sf.net/event/
> >
> > I hope it can indeed provide a good basis for that :-)
> >
> > According to your examples, it would be something like:
> >
> > sioc:has_creator rdfs:subPropertyOf event:agent. sioc:has_container
> > rdfs:subPropertyOf event:factor. ?
> >
> >
> > Cheers! y
> >
>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

SIOC, IRC and events

John Hoogstrate wrote:
> Hi,
>
> I have some experience with designing and implementing online events
> which export to RSS, iCalendar and SIOC. In my case I used the
> event-module for the SIOC output because it was the only one available
> at that time, and it is fairly limited.
> http://purl.org/rss/1.0/modules/event
>
> I don't think using an iCalendar ontology is a good idea for events.
> iCalendar is a format intended to be interchangable between calendering
> applications, not to describe events in the best way possible. A great
> number of the properties of iCalendar belong in different ontologies. It
> supports todo's and alarms and other things that have absolutely nothing
> to do with events.

A superset of what is needed is not a disadvantage, right? And as you
correctly point out: iCal IS used in applications, ie. is a de facto
standard which shouldn't be competed, but completed ;)
I could import/export events tied to SIOC descriptions to/from my
calendar... doesn't sound bad to me.

Whatever is proposed, should thus at least foresee a mapping to iCal.

For some work on ontology framweorks with mappings as I envision them,
see [1,2]

best,
axel

1.Boanerges Aleman-Meza, Uldis Bojars, Harold Boley, John G. Breslin,
Malgorzata Mochol, Lyndon J.B. Nixon, Axel Polleres, and Anna V.
Zhdanova. Combining RDF vocabularies for expert finding. In Enrico
Franconi, Michael Kifer, and Wolfgang May, editors, Proceedings of the
4th European Semantic Web Conference (ESWC2007), volume 4519 of Lecture
Notes in Computer Science, pages 235-250, Innsbruck, Austria, June 2007.
Springer.
http://www.polleres.net/publications/alem-etal-2007.pdf
Slides available at
http://www.polleres.net/publications/alem-etal-2007eswc-slides.pdf.

2. Axel Polleres, François Scharffe, and Roman Schindlauer. SPARQL++ for
mapping between RDF vocabularies. In OTM 2007, Part I : Proceedings of
the 6th International Conference on Ontologies, DataBases, and
Applications of Semantics (ODBASE 2007), volume 4803 of Lecture Notes in
Computer Science, pages 878-896, Vilamoura, Algarve, Portugal, November
2007. Springer.
http://www.polleres.net/publications/poll-etal-2007.pdf

> Not to mention the fact that it allows for custom
> extensions to be made that are undefined potentially making a perfectly
> valid iCalendar file impossible to translate.
>
> Using a new ontology will provide more flexibility and simplicity while
> it will still be possible to automatically transform it to iCalendar for
> backward compatiblity.
>
> The draft at http://motools.sf.net/event/ looks good, but it definetely
> needs a way to define the status of the event, since the existence of a
> future event is still uncertain until it has actually happened.
> iCalendar allows for an event status to be set to
> confirmed, tentative, cancelled which is very useful. Through
> experience I found out that another status in the likes of 'sold out'
> or 'booked full' would also be very useful.
>
> Greetings,
>
> John
>
> Axel Polleres wrote:
>> Yves Raimond wrote:
>>> Hi Alexandre!
>>>
>>> [snip]
>>>
>>>> This Event class could be defined in the SIOC core itself, but we
>>>> may also reuse (or subclass) existing Event classes from other
>>>> ontologies (I didn't look yet, but I think that iCal / music
>>>> ontology Events may fit there), and use - sioc:has_creator -
>>>> sioc:has_container - dcterms:created - dc:description to define
>>>> event property and link it to associated Container / User
>>
>> For referring to/annotating events: wouldn's iCal/RDF be a natural
>> hook? There is a translator from iCal to RDF at:
>> http://www.kanzaki.com/courier/ical2rdf equally related the hCalendar
>> microformat version of iCal: http://microformats.org/wiki/hcalendar
>>
>> axel
>>
>>
>>> Just a small comment: we published last week a documentation draft
>>> for the event ontology we use in MO. It is available there:
>>>
>>> http://motools.sf.net/event/
>>>
>>> I hope it can indeed provide a good basis for that :-)
>>>
>>> According to your examples, it would be something like:
>>>
>>> sioc:has_creator rdfs:subPropertyOf event:agent. sioc:has_container
>>> rdfs:subPropertyOf event:factor. ?
>>>
>>>
>>> Cheers! y
>>>
>>
>
>
>
> >
>

--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

SIOC, IRC and events

Hi all,

>
> Just a small comment: we published last week a documentation draft for
> the event ontology we use in MO. It is available there:
>
> http://motools.sf.net/event/
>
> I hope it can indeed provide a good basis for that :-)
>
> According to your examples, it would be something like:
>
> sioc:has_creator rdfs:subPropertyOf event:agent.
> sioc:has_container rdfs:subPropertyOf event:factor. ?
>

+1

Fred

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---