> On Tue, 2 Jul 2019 at 17.06, Siddhesh Rane wrote:
>
>> Just out of curiosity, RDF is mostly for semantic data that has some
>> meaning.
>> If you are quring using keys that are essentially random strings,
>> would it not be more suitable to use a relational database?
No or better said, not sure
URIs do not have semantic meaning, they are opaque identifiers.
https://www.w3.org/DesignIssues/Axioms.html#opaque
On Tue, 2 Jul 2019 at 17.06, Siddhesh Rane wrote:
> If the URL is some REST endpoint then you can map UUID in the URL to
> binary keys in the database.
> If your URLs are RDF resour
On 02/07/2019 18:06, Siddhesh Rane wrote:
If the URL is some REST endpoint then you can map UUID in the URL to
binary keys in the database.
If your URLs are RDF resource identifiers, then better to stick with
hyphenated UUID form that is standard.
Yes they are.
Just out of curiosity, RDF i
If the URL is some REST endpoint then you can map UUID in the URL to
binary keys in the database.
If your URLs are RDF resource identifiers, then better to stick with
hyphenated UUID form that is standard.
Just out of curiosity, RDF is mostly for semantic data that has some meaning.
If you are qur
This is handy to know, but in this case we are serving data over the id
URLs, so that's why https://example.com type.
On 02/07/2019 11:47, Claude Warren wrote:
I agree with Andy, but note that there is a URN specification for UUID (
https://tools.ietf.org/html/rfc4122)
So the URI would be
One area where performance hit occurs is when the data being accessed
is not in memory, requiring disk IO.
Assuming database files are cached in RAM, you could fit more entries
in one page if the key size was smaller, reducing the probability of
cache misses.
Better way is to go with standard appro
I agree with Andy, but note that there is a URN specification for UUID (
https://tools.ietf.org/html/rfc4122)
So the URI would be urn:uuid:
I used this in a recent project.
Claude
On Tue, Jul 2, 2019 at 8:53 AM Andy Seaborne wrote:
> I doubt one URI design vs another where it will make any ob
Thanks for replies. I was thinking of a case where there are billions of
triplets and search could be slightly faster because of shorter string
lenght. But yes, if the difference is few milliseconds here or there
it's not worth it...
On 02/07/2019 10:52, Andy Seaborne wrote:
I doubt one U
I doubt one URI design vs another where it will make any observable
difference.
Andy
On 01/07/2019 18:50, Siddhesh Rane wrote:
You could save the UUID as a 128 bit number in the database.
Conversion between alphanumeric and byte encoded UUIDs can be done on
the fly.
This would be the most
You could save the UUID as a 128 bit number in the database.
Conversion between alphanumeric and byte encoded UUIDs can be done on
the fly.
This would be the most compact solution compared to text format.
Regards
Siddhesh Rane
On Mon, Jul 1, 2019 at 9:02 PM Mikael Pesonen
wrote:
>
>
> We are now
We are now using UUIDs for resource ids, e.g.
https://example.com/f0c6b590-0bd6-4c66-8872-f6a0f3aa33ac where id length
is 38 characters.
Would it be any better performance wise to use more compact id
https://example.com/jgie3590roGvnfsjvGUEu using 21 alphanum characters
UUID is a standard
11 matches
Mail list logo
