Proposed new property: sioc:source: for aggregated content
John Breslin
In the course of doing some SIOC output from an aggregator, we think
there is a need for sioc:source to point at the original of an
aggregated post or blog.
If you have any ideas or suggestions for something like this (or
sioc:original), let us know - thanks!
John.
--
Dr. John Breslin
DERI, NUI Galway
http://sw.deri.org/~jbreslin/
john.b...@deri.org
John Breslin
AggregatedWeblog and AggregatedBlogPost ...
John.
--
Richard Cyganiak
How about essentially republishing the RDF from the sources, with
their original identifiers? My gut feeling is that an aggregator
shouldn't introduce new identifiers for the aggregated content.
Richard
Alexandre Passant
Good point for the sioc:source, it can especially be used when
blogging from rss feeds, as in reblog.org
Regarding AggregatedBlogPost type, I'm currently using a RSSItem class
to say that something is an agregated item from external source (no
difference between rss item from blog, wiki, newsfeeds ...). I defined
it as both a subclass of rss:Item and sioc:Item.
What we could have, thus, is a hierarchy like:
- sioc:Container
-- AgregatedContainer
--- AgregatedBlog
--- AgregatedWiki
--- AgregatedXXX
- sioc:Item
-- sioct:AgregatedItem / sioct:RSSItem
--- sioct:AgregatedBlogPost
- rss:Item
-- sioct:AgregatedItem / sioct:RSSItem
It might seem complex but offer nice expressivity power I think - eg,
in my use case, retrieving all sioc:Item => internal blogs, wikis, rss
feeds, but also ability to restrict to external news only, etc ...
Alex.
John Breslin
content.
RSS feeds often truncate the original content, and aggregators may also
parse it for storage or for removing JS etc...
J.
--
Richard Cyganiak
On 29 May 2008, at 14:07, John Breslin wrote:
> The problem Richard is that aggregators don't always have the original
> content.
>
> RSS feeds often truncate the original content, and aggregators may
> also
> parse it for storage or for removing JS etc...
So, use dcterms:abstract (or a hypothetical sioc:excerpt property)
instead of sioc:content? I don't think it matters if the descriptions
are byte-for-byte identical.
My point was more that an aggregator provides information about the
*same* entities in a somewhat different configuration. An
AggregatedPost is not a new entity, it's still the same entity as
before, accessible in a new location, and possibly with somewhat
different properties.
(Imagine a FOAF aggregator. Would it create new URIs for all people,
and use foaf:source to connect the new URIs to the original URIs? This
doesn't seem right to me.)
Richard
John Breslin
hear some more ideas for a consensus.
Even if the same URI is used, maybe a sioc:source property to point to
the original location of the data would help? Or is it enough to know
that since it is on a different domain, then it is a copy?
J.
--
Richard Cyganiak
On 29 May 2008, at 16:34, John Breslin wrote:
> I don't know for sure - :-) - you've a good argument, but I'd like to
> hear some more ideas for a consensus.
Me too!
> Even if the same URI is used, maybe a sioc:source property to point to
> the original location of the data would help?
Sounds like a good idea. Sometimes though (if content negotiation is
used) the sioc:source would be just the URI of the post itself.
Richard
James Howison
between a URI as a *name* and a URI as a *locator*. ie the original
post is the same resource, but now it is in a different location. The
URI to describe the resource shouldn't change, but now there is an
alternative location for discovering it. Seems similar to the "work"
and "instantiation" difference that ontologies for books etc deal with.
If the content is indeed changed, and I think you are suggesting that,
then this is perhaps akin to an Edition of the original resource (but
the original resource URI still shouldn't change). Which, now I think
about it, is what you are proposing :) A new Class of resource that
has a well-defined semantic relationship to the original resource (eg
the new resource truncates the text of the original resource).