On 5/29/07, Kingsley via proxy of John Breslin wrote:
> > free text. But what if we want to say that a particular Post describes
> > a book or is about two books, perhaps something like sioc:about or
> > sioc:describes is needed.
>
> Why not Tag (via SKOS) the post for this purpose? The rest of the
> specificity should be in the content of the post (i.e. content
> structure).
>
> A Post about a book could be a "Book Review" or a Post that mentions
> the Book. If it is a "Book Review" then a sioc:Item subclass for
> "Reviews" should be adequate. If it's a Post that mentions a book then
> "sioc:related" should suffice. Otherwise, just Tag the post.

Tagging alone will not help here. For the same reason why people came
up with the structured blogging or microformats while they could have
used simple tags "business card", "review", ...

Two reasons:

1.1) Tags are often local to the site. SKOS or not matching tags from
different sites is going to be a difficult task. And since tags are
text-based you will have different names for book reviews in many
languages. Does not sound like a place for tags or SKOS when you can
define facts like this very precisely with RDF.

1.2) Even if you knew that this is a book review, you need to point to
the Book it describes, or to a Review the post contains which point to
the Book itself. We need a property that will link a post to one or
more objects (e.g., a Book) it is about. Once we have this linking
property, we can explicitly define the type of its object [ _a a
publications:Book ].

The suggestion about tagging is applicable in another situation -
tagging something as a "Book review" can be a simple way for end users
to indicate it is a review. The application (SIOC plugins, ODS, ...)
will take this hint and extract all the detailed RDF from the post. It
will still need to be supplied with the information about the object
(e.g., a Book), possibly supplied in the post.

> > (4)
> >
> > I am of the opinion that a Community is NOT a subclass of Space. A
> > Space is where data resides, but a community extends beyond mere data.
> >
> Community is Data.
> Data is atomic when dealing with Networks, really.
> A Community is one representation of Data in specific context (be it
> your AddressBook, Blogroll, Boardscape etc..). A Community is a type
> of Data Space.

The root of these problems is that both classes are new and not
applied in SIOC data in practice. That means they are not grounded in
real implementations and the only thing how we can determine their
meaning is by how they are described in the ontology and its
specification.

How can you tell if "Something A" is a subclass of "Something B" if we
have not really tested either. All depends on the definition then (and
we are free to change the definition in the ontology before we
finalise the specification).

If the definition of a Space is a "space where data reside", then
community is not a Space because people (foaf:Persons) can also be
part of a Community and they sure are not data (in the common
understanding). From this point we have a question - what is easier? -
(a) to leave out the subclass, and add it later if needed; or (b) to
add it now and try to remove it if we find it not suitable. It is hard
to take a statement away, so in my view (a) is a better chioce now.

What we can do is: revise definitions for both classes, coming up with
more precise definitions if needed. And build implementations that use
this data, which (how it is used) determine in the end real meaning of
the data.

> I hope SIOC provides a mechanism for coherent construction of rich
> URIs (rich is expressed in depth and breadth of Linked Data).

It is not a part of the ontology specification, but SIOC plugins for
WordPress, etc. have implicit rules how the URL to request some data
can be formed. Currently it is not explicitly defined in the documents
of SIOC project, but we may think about it and work on the SIOC
protocol description as a way to construct rich URIs to request SIOC
data.

> > (5)
> >
> > We still need a way to recommend to people looking at the SIOC Types
> > module what kind of vocabularies can be used for Items contained in
> > particular Container subclasses. For example, to say that in a
>
> I think being able to dereference the Schema / Ontology is a starting
> point. Ultimately, RDF Authors (direct or indirect) will lookup
> dereferencable ontologies and use this as an unobtrusive mechanism for
> "Term ReUse". If I can dereference the SIOC Types Modules I can

What we need before that is a way how to point to other ontologies.

Your initial approach was to subclass those external classes form
sioc:Item thus indicating they all (doap:Project, image:IFD, ...) are
items. This makes sense from the business point of view, but is
intrusive into those other ontologies.

We need to find a way that is less intrusive (does not change
definitions of the external ontologies, if possible) and at the same
time hint that these ontologies can be used to represent a particular
type of objects.

rdfs:seeAlso is probably the weakest / less instructive possible way
to indicate this.

Which may be good for start, unless we find something that is good,
stronger than seeAlso and weaker than subclassing external things from
sioc:Item. In the future we can use related ontologies schema to link
different schemas, but we have to materialise this schema first.

Uldis

[ http://captsolo.net/info/ ]

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---