Storing long address occurrences
F. Andy Seidl
characters (at least in the MySQL RDBMS implementation). For
occurrence addresses longer than 255 characters, the address can be
stored as a DataTypes.TYPE_STRING value, thus allowing up to 2**16
characters (in MySQL).
I am wondering if there are any significant pros or cons to either of
these possible approaches to supporting longer occurrence addresses:
1) simply store ALL addresses as DataTypes.TYPE_STRING values and
avoid using DataTypes.TYPE_URI at all;
2) store short addresses as TYPE_URI and long addresses as STRING and
have the application sort what it has; or
3) alter db schema used by the TM_OCCURRENCE table to specify a larger
value for the datatype_address column (e.g., varchar(4096)).
Thanks,
-- fas
Lars Marius Garshol
* F. Andy Seidl
>
> I am wondering if there are any significant pros or cons to either of
> these possible approaches to supporting longer occurrence addresses:
>
> 1) simply store ALL addresses as DataTypes.TYPE_STRING values and
> avoid using DataTypes.TYPE_URI at all;
The downside with this is that if you then interchange this data with someone they have no way of knowing that these strings are in fact URIs. Omnigator and Ontopoly will not treat these strings as URIs, either, in the sense that they won't turn them into links and so on.
It's not the end of the world, but I'd try to avoid this.
> 2) store short addresses as TYPE_URI and long addresses as STRING and
> have the application sort what it has; or
My immediate reaction to this is "yuck!" :-) I think it's better to be consistent.
> 3) alter db schema used by the TM_OCCURRENCE table to specify a larger
> value for the datatype_address column (e.g., varchar(4096)).
Apart from the obvious database performance concerns (and those probably aren't noticeable) I can't think of any reason not to do this.
--Lars M.
http://www.garshol.priv.no/tmphoto/
http://www.garshol.priv.no/blog/
F. Andy Seidl
There's a fourth alternative that may be better yet. Leave everything
on Ontopia as it is, including the 255 char limit on URIs. But in the
platform API that I'm layering on top of Ontopia, use a (private) URL
shortening service similar to bit.ly to squeeze/unsqueeze URIs on the
way in and out of Ontopia.
From the outside, it will look like the system has no URI size
restrictions. Tool like omnigator and ontopoly will continue to work
with the URIs correctly, albeit in thier (potentially) shortened
forms. No db schema changes to worry about maintaining.
The main downside is that it limits the usefulness of string
predicates on URI addresses (e.g.: contains(URI, "google.com"). But I
suppose even that could be dealt with, if necessary, using a custom
predicate impl that knew about the shorter service.
-- fas
On Dec 18, 7:44 am, Lars Marius Garshol <lar...@garshol.priv.no>
wrote:
Lars Marius Garshol
* F. Andy Seidl
>
>>
> From the outside, it will look like the system has no URI size
> restrictions. Tool like omnigator and ontopoly will continue to work
> with the URIs correctly, albeit in thier (potentially) shortened
> forms. No db schema changes to worry about maintaining.
True. And I guess if the shortener is private there's no need to worry about the delay of network connections etc.
> The main downside is that it limits the usefulness of string
> predicates on URI addresses (e.g.: contains(URI, "google.com"). But I
> suppose even that could be dealt with, if necessary, using a custom
> predicate impl that knew about the shorter service.
It could.
I guess another downside is the general one of URL shorteners: it causes duplicate URIs for the same resources to multiply, potentially confusing semantic systems that rely on URI matching for identity. This is especially an issue if you start exchanging fragments with other services.