RE: Can json-ld convert identifiers to IRIs?

On Tuesday, July 10, 2012 8:08 PM, Stéphane Corlosquet wrote:
> While I agree that putting an identifier inside a URI makes sense 
> when publishing data online, I find it simpler to work with simple
> IDs internally. One could argue that URIs can be the ids used
> internally, but I find that inconvenient when combining it into a
> URI again (you'd have URIs inside URIs).

I don't see any problems if you internally use simple IDs internally, in
fact, I think this is the most common scenario in Web APIs anyways. Most (if
not all) Web frameworks these days do all the work of creating/parsing IRIs
for you automatically.


> There is also the fact that the namespace you use in front of
> your ID could change depending on what server is generating 
> these URIs at the first place.

The question here is, if you really would like to treat the data as equal
then or whether you see it as two different records? If your concern is
regarding the publishing process you can of course use relative IRIs to
alleviate that.


> Using ID (and in particular UUIDs), you are sure to never 
> have to change these IDs to match whatever new application
> namespace, and you know this unique ID will always refers to the
> same entity across all instances using your data.

You lose a lot functionality because you can't dereference such identifiers
to get more information about an entity but nothing prevents you from using
the uuid scheme [1].


> Using URIs also forces you to think of namespaces and URI patterns
> ahead of time, which you might not want to do initially when
> prototyping as they could change with your application needs. See
> another similar story at [1].

It's just a problem if you work with production data in your prototypes and
other people link to that data from their applications. If that's not the
case, it doesn't really matter.


> Don't get me wrong, I'm all for URIs when publishing Linked Data on the
> Web, I just think that there are situations where regular IDs can be
> more useful than URIs.

Sure.. often you can provide both to get the best of both worlds as I
outlined in my previous mail.


[1] http://www.ietf.org/rfc/rfc4122.txt



--
Markus Lanthaler
@markuslanthaler