gistfile1.rb

# Note that as in the SIOC reference documents, the extended SIOC types
# ontology is referred to as sioc_t.

It would seem that 'reference implementations' of existing ontologies are
actually quite difficult in Spira.

sioc:topic references an RDF Resource.  That Resource may optionally be a
sioc_t:Category or sioc_t:Tag.  sioc_t:Category is a subclass of skos.Concept,
but sioc_t:Tag is its own thing.

What, then, should a 'reference implementation' of SIOC do for a topic?  Is it
even meaningful to have a 'reference implementation' when the targets of many
of the predicates very specifically have no range of possible types?

For example:

module SIOC
  class Post < Item
    include Spira::Resource
    has_many :topics, :type => ???, :predicate => SIOC.topic
  end
end

The :type above signifies the type that the target of this property will take
in Ruby, such as an RDF::URI, a String, an Integer, or another Spira class.
What should the :type above be?

* An RDF::URI?  This allows, for example,
`Post.for(uri).topics.first.as(sioc.Category)`. But is that useful?

* Some superclass that encapsulates both sioc_t:Category and sioc_t:Type?  Such
a superclass is not defined in SIOC.

* Just pick one?  Or allow end users to override and pick one?

Another possibility is not possible with Spira as-is.  Spira properties are
defined by the predicate associated with a given resource, so categories and
tags are both the same tag.  But a more generic relations mechanism might allow
predicate targets to be sorted into varying fields based on other information,
such as RDF type(s).  

module SIOC
  class Post < Item
    include Spira::Resource
    has_many :tags, :predicate => SIOC.topic, :rdf_type => SIOC_T:Tag
    has_many :categories, :predicate => SIOC.topic, :rdf_type => SIOC_T:Category
  end
end

This allows Spira to represent a wider array of concepts 'natively', but I'm
not so sure it's useful.  The point of Spira is that you're taking RDF data and
putting it into Ruby objects that are easy to use.  Is this really met by
allowing users to define models that can ask 'What is this?' or 'Does this item
have this?', or even worse, 'Does this item have categories, tags, both, or
none?'  I'm not sure such a flexible model is actually what any user wants.

It seems more likely to me that people will want something that makes it easy
to create and load information for their particular dataset.  I think perhaps
something more useful would be to provide a Spira class which has some
interrogation on the actual RDF statements associated with it, and which has
the #as(klass) method, just like RDF::URI.  This class would, in particular,
have some helpers for RDF types to allow one to determine how best to represent
it.  Consider the fictional Spira::Typecaster:

@post.topics.first # Spira::Typecaster (or whatever it's named)
@post.topics.first.a?(SIOC_T.Tag)      # => true if the given resource has an RDF.type of SIOC_T.Tag
@post.topics.first.a?(SIOC_T.Category) # => true if the given resource has an RDF.type of SIOC_T.Category

This is the tool people would need to implement truly open-world flexibility.
For example, === can be true for URIs for which the given resource has an
RDF.type of:

class Spira::Typecaster
  def ===(other)
    self.query(:predicate => RDF.type, :object => other).count > 0
  end
end

# meanwhile, in other code...
topic_names = @post.topics.map do |topic|
  case topic
    when SIOC_T.Tag
      topic.as(SIOC_T::Tag).label
    when SIOC_T.Category
      topic.as(SIOC_T::Category).name
    else
      topic.uri
  end
end

I think this is going to be The Right Way To Do It.  But it means that most of
the properties in any 'reference implementation' will be these
Spira::Typecasters, not terribly useful for any actual use case--just providing
a flexibile base for real use cases.  Is there really any value to a reference
implementation, then?  It's certainly not going to make for a whizbang blog
post.