SIOC's more generic classes are underspecified
Richard Cyganiak
I'm working on a soon-to-be-published vocabulary for describing RDF
datasets (called voiD), and members of the SIOC community (Alex
Passant and Simon Reinhardt) have asked for alignment between voiD and
SIOC.
I'm trying to figure out how this could be done. And while SIOC is
pretty self-explanatory for describing things like forums and blogs, I
have a lot of trouble figuring out its higher-level, more generic
concepts, which seem a bit underspecified to me. So, here are some
questions.
1. Is a can of beer a sioc:Item, and a box of beer a sioc:Container?
2. What is the difference between sioc:Space and sioc:Container?
3. If A and B are sioc:Containers, and A sioc:parent_of B, and B
sioc:container_of xyz, does it follow that A sioc:container_of B?
4. Would “All posts published on a Tuesday” be a valid child
sioc:Container of a sioc:Forum?
Please do *not* give me any answers that explain SIOC concepts by
referring to other SIOC concepts. “A sioc:Container is something that
contains sioc:Items” is not helpful, please use terminology from the
non-SIOC world. Also, quotage from the SIOC spec would be appreciated.
I realize that some of those questions might not have clear-cut
answers and that's okay, so if you have any opinion then please fire
away, I'm more interested in discussion than YES/NO style answers
anyway.
Cheers,
Richard
--
Richard Cyganiak
DERI, NUI Galway
skype:richard.cyganiak
tel:+353-91-49-5711
Breslin, John
> 1. Is a can of beer a sioc:Item, and a box of beer a sioc:Container?
IMO no. We are talking about Containers and Items in terms of community
content, i.e. content that is data-based... Not real-world objects.
> 2. What is the difference between sioc:Space and sioc:Container?
A Space is a place where data resides, e.g. a website, a file share, a
peer on a P2P network, an external hard drive. A Container is more like
a channel, a folder, a gathering of content items such as blog posts,
images, bookmarks, etc.
> 3. If A and B are sioc:Containers, and A sioc:parent_of B, and B
sioc:container_of xyz, does it follow that A sioc:container_of B?
Yes, is that a problem I wonder?
> 4. Would "All posts published on a Tuesday" be a valid child
sioc:Container of a sioc:Forum?
Sounds more like one view or filter of content items that is logically
linked to a container - but I guess you could if you wanted...
Good questions all! Let's have some more opinions / answers...
John.
Simon Reinhardt
On Feb 9, 2:30 pm, "Breslin, John" <john.bres...@nuigalway.ie> wrote:
> Hullo Richard and all -
>
> > 1. Is a can of beer a sioc:Item, and a box of beer a sioc:Container?
>
> IMO no. We are talking about Containers and Items in terms of community
> content, i.e. content that is data-based... Not real-world objects.
but the described resource wouldn't be - http://dbpedia.org/page/Cambridge
and http://dbpedia.org/data/Cambridge.rdf would be sioc:Items,
http://dbpedia.org/resource/Cambridge wouldn't, right?
But doesn't that contradict the whole discussion on
http://groups.google.com/group/sioc-dev/browse_thread/thread/132eaa291d93fb73/e8388393ca167985
which lead to change "content items" to "container items"?
Regards,
Simon
Richard Cyganiak
On 9 Feb 2009, at 14:30, Breslin, John wrote:
>> 2. What is the difference between sioc:Space and sioc:Container?
>
> A Space is a place where data resides, e.g. a website, a file share, a
> peer on a P2P network, an external hard drive. A Container is more
> like
> a channel, a folder, a gathering of content items such as blog posts,
> images, bookmarks, etc.
This still sounds fuzzy to me. Isn't a folder also a place where data
resides? Isn't a website also a gathering of content items? I cannot
tell wether a void:Dataset is “a place where data resides” or “a
gathering of content items.” The distinction seems arbitrary to me.
Why was it made in SIOC?
>> 3. If A and B are sioc:Containers, and A sioc:parent_of B, and B
>> sioc:container_of xyz, does it follow that A sioc:container_of B?
>
> Yes, is that a problem I wonder?
Ah, I goofed when I wrote the question, very sorry about that! What I
meant is this:
:my_container a sioc:Container
:my_parent_container a sioc:Container
:my_parent_container sioc:parent_of :my_container
:my_container sioc:container_of :my_item
So, there is an item which is in a container, and the container has a
parent. Does it follow that the parent also contains the item? In
other words, are parent containers also containers of their children's
items?
Note that for example in file systems we don't typically think of it
that way. If a file is in /home/cygri/stuff/xyz, then we do *not* say
that it is also in my home directory. (We'd say something like “it's
somewhere under my home directory.”)
The answer to this matters for the question wether void:Dataset can be
declared a subclass of sioc:Container.
Cheers,
Richard
Alexandre Passant
Le 9 févr. 09 à 22:31, Richard Cyganiak a écrit :
children's item, we should define a rule to say this.
And if there's no rule, then there's no reason to consider that the
parent contain the items.
So, do we need that rule ?
Regarding a querying point of view, that would make sense.
List all items in X will also retrieve items contained in Y where X is
a parent of Y.
Yet, as you mentioned in the filesystem example, we generally do not
consider that the file is in a folder when it's in a subdirectory.
From a querying point of view, it would be like a 'ls' comment
listing not only items in the folder but in the folder + all subfolders.
So, the rule may be needed, with either:
1) A way to launch the following rule when running the SPARQL queries.
Unfortunately, that rule cannot be expressed as a basic OWL/RDFS rule
(maybe in OWL2 ?) and would require something like N3 / RIF to be
defined. I don't know how SPARQL plan to deal with that.
{
:my_container a sioc:Container .
:my_parent_container a sioc:Container .
:my_parent_container sioc:parent_of :my_container .
:my_container sioc:container_of :my_item .
}
=>
{
:my_parent_container sioc:container_of :my_item .
}
2) A rule that introduces another property, such as
'full_container_of' (defined as a superproperty of container_of)
{
:my_container a sioc:Container .
:my_parent_container a sioc:Container .
:my_parent_container sioc:parent_of :my_container .
:my_container sioc:container_of :my_item .
}
=>
{
:my_parent_container sioc:full_container_of :my_item .
}
Then we would be able to ask either items contained directly in a
container (container_of) or in a container and all its "sub-
containers" (full_container_of)
Hope that helps,
Alex.
> The answer to this matters for the question wether void:Dataset can be
> declared a subclass of sioc:Container.
>
> Cheers,
> Richard
> >
Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .
James Howison
Yes, this is what I did when I was modeling email lists and
threads[1,2]. I wanted the list to be linked individually to each
message, not just indirectly through the Threads (and above that each
message linked to the project that had the mailing list). I *think*
that this can be done with role chains in OWL2, but I couldn't make it
work, so I first used an SWRL rule as you describe, then that was too
slow so I used a SPARQL CONSTRUCT query, added the result back in to
the original Model (graph/ontology/dataset) and then queried the
combination.
:list1 a fc:MailingList ;
fc:hasThread :thread1 .
:thread1 a fc:MailingListThread ;
fc:hasEvent :message1 .
:message1 a fc:MailingListEvent ;
fc:isEventOf :thread1 .
fc:hasThread(?list, ?thread) ^ fc:hasEvent(?thread, ?event) ->
fc:hasEvent(?list, ?event)
Of course this means that one either has no domain for fc:hasEvent, or
has a Union domain.
I agree, however, that the file folder example above doesn't have
those semantics, so such rules would need to be expressed either
through a different type of property (that 'reaches' down into the
tree) or defined only for subClasses of sioc:Container.
AFAIK, SPARQL isn't intended to handle this directly, the expectation
is that you are querying a realized set of data where semantics like
this are already expressed (through the semantics of RDF/OWL/SWRL and
a reasoner). ARQ property paths might handle it though.
--J
[1]: http://floss.syr.edu/ontologies/2008/
[2]: http://floss.syr.edu/ontologies/2008/flosscomms-sketch.pdf
kidehen
On Feb 9, 10:30 am, "Breslin, John" <john.bres...@nuigalway.ie> wrote:
> Hullo Richard and all -
>
> > 1. Is a can of beer a sioc:Item, and a box of beer a sioc:Container?
>
> IMO no. We are talking about Containers and Items in terms of community
> content, i.e. content that is data-based... Not real-world objects.
>
sioc:Item is not type foaf:Document.
Kingsley
kidehen
On Jan 22, 1:07 pm, Richard Cyganiak <rich...@cyganiak.de> wrote:
> All,
>
> I'm working on a soon-to-be-published vocabulary for describing RDF
> datasets (called voiD), and members of the SIOC community (Alex
> Passant and Simon Reinhardt) have asked for alignment between voiD and
> SIOC.
>
Others:
sioc:Container and sioc:Item are no document type classes.
SIOC is not just about Forums. It is about Spaces for accessing Data
on the Linked Data Web.
Hopefully via SIOC and FOAF we have solid foundation for coherent,
usable, and demonstrable "Linked Data Web".
To really understand going beyond paper and the traditional file/blob,
do watch the Hyperland Documentary (see my blog) and some of Ted
Nelson's talks about Transclusion.
Putting semantics aside, Ted and Tim have been talking about the same
thing in different ways for eons.
Hopefully, SIOC and FOAF could also accelerate the recoonection of
these and other world views about data access.
The "File" and "Paper" are vehicles of resource description
representtion. Do not let them obscure pathways to referents behind
URIs.
Kingsley
Breslin, John
>
> IMO no. We are talking about Containers and Items in terms of community
> content, i.e. content that is data-based... Not real-world objects.
>
k: sioc:Item is not type foaf:Document.
Okay, just saw this now - then we have a difference of opinion! What do others think?
Thanks,
John.
Simon Reinhardt
> Okay, just saw this now - then we have a difference of opinion! What do others think?
determine how generic they are.
On the one hand what is the point in having a super-class of sioc:Post
if it's just a "content item"? What exactly is a "content item" and
what makes sioc:Post more specific than that?
On the other hand if sioc:Item is any sort of item what makes it more
specific than any other thing?
What are the properties with range or domain of sioc:Item that don't
work with every kind of resource? And what are they properties with
range or domain of sioc:Post that don't work with every kind of
sioc:Item?
Regards,
Simon
kidehen
intention. By adding them to SIOC, SIOC becomes a much more abstract
in scope. a sioc:Post is a subclass of a sioc:Item.
I'll look at the current definitions of sioc:Container and sioc:Item
to see if their domains and ranges are reflective of their intended
use etc..
Kingsley
> Regards,
> Simon
Alexandre Passant
Le 29 mars 09 à 16:28, kidehen a écrit :
>
> Simon,
>
> On Mar 26, 5:38 pm, Simon Reinhardt <simon.reinha...@gmail.com> wrote:
>> On Mar 26, 8:41 pm, "Breslin, John" <john.bres...@nuigalway.ie>
>> wrote:
>>
>>> Okay, just saw this now - then we have a difference of opinion!
>>> What do others think?
>>
>> I think since Kingsley proposed those more generic classes he should
>> determine how generic they are.
>> On the one hand what is the point in having a super-class of
>> sioc:Post
>> if it's just a "content item"? What exactly is a "content item" and
>> what makes sioc:Post more specific than that?
>> On the other hand if sioc:Item is any sort of item what makes it more
>> specific than any other thing?
>> What are the properties with range or domain of sioc:Item that don't
>> work with every kind of resource? And what are they properties with
>> range or domain of sioc:Post that don't work with every kind of
>> sioc:Item?
>>
> sioc:Item and sioc:Container are generic. That has always been my
> intention. By adding them to SIOC, SIOC becomes a much more abstract
> in scope. a sioc:Post is a subclass of a sioc:Item.
>
sioc:Item, i.e. not only online things but for instance a garage and
some cars ?
If so, what's the difference compared to rdf:Resource and, e.g,
rdf:Bag ?
Thanks
Alex.
> I'll look at the current definitions of sioc:Container and sioc:Item
> to see if their domains and ranges are reflective of their intended
> use etc..
>
> Kingsley
>> Regards,
>> Simon
> >
kidehen
On Mar 29, 11:54 am, Alexandre Passant <alexandre.pass...@deri.org>
wrote:
Good question.
Answer:
If rdf:Resource and rdf:Bag addressed this subtle issue, wouldn't they
be in broad use rendering this whole conversation moot?
Basically, would we not have a profileration of data spaces that
expose:
1. Favorite Things
2. OfferLists
3. WishLists
4. etc?
I am attempting to use SIOC to provide a clear mechansim (closed
vocab) for making statements about "Things" and "Collections of
Things".
What I am trying to do with SIOC doesn't break anything (as I see it).
Nothing stops sioc:Container from being a subclass of rdfs:Container
and sioc:item a subclass of rdfs:Bag.
I still don't really get you basic gripe with these suggestions when
they address issues like:
1. Wishlists, OfferLists, PlayLists, Favorites with a temporal aspect
(we seek many things over a period of time in our lives, sioc:item has
a slot for "creation time" I don't see the rdf:bag solution to this
matter)
2. Easy construction of Linked Data Web queries that are simpliefied
via closed vocabulary of SIOC e.g. the example above: What was my
facvorite record in 1978? What where my top Wishlist items in 1990
(which may include a Garage) etc..
If you have a better solution, I am all ears. I just want a solution
and I see SIOC as a great vehicle.
Kingsley
kidehen
Little correction, I meant: "controlled vocabulary", not "closed
vocabulary" in my earlier post :-)
Kingsley