Bug 30263

An alternative is to use data:// URI scheme to store the data directly, especially since such a stored object won't have any other URI(unless we come up with something).

A related use case that we need to consider is storing a copy of data in the database.

It can be implemented by 2 DOs: one with data:// URI and another the "real" one, both linked together by copy relationship.

Alternatively, it can be implemented by a slight tweak of your proposal: introduce also nie:CachedDataObject to differentiate cached DOs from the ones primarily stored in the database; or change nie:textContent and nie:binaryContent domain to nie:DataObject to let you freely store caches and use StoredDataObject as a marker for DOs primarily stored in the database.

Caches, however, tend to get out of date, especially if we talk about remote resources. Should we care? Should we store the last fetch date? Where should we store it: DO itself or use existing graph metadata?

Ideas?

Sorry for derailing such a simple change request but it's really a close topic.

I do not follow your data:// approach. Where would the data actually be stored then? In the URI itself?

Do you have a use case for the caching idea?
If so I would be fine with introducing CachedDataObject and changing the domain of the properties to nie:DataObject.

(In reply to comment #2)
> I do not follow your data:// approach. Where would the data actually be stored
> then? In the URI itself?

http://en.wikipedia.org/wiki/Data_URI_scheme

> Do you have a use case for the caching idea?
> If so I would be fine with introducing CachedDataObject and changing the domain
> of the properties to nie:DataObject.

I was thinking about Akonadi here and their desire to use Virtuoso, or some nepomuk services working with remote resources. Won't they want to keep cached copies around?

If I understand correctly we could just put a data: URI into the nie:url property and KIO would properly load the data. That would indeed be simple and not really require new types.