Re: Can json-ld convert identifiers to IRIs?

On Tue, Jul 10, 2012 at 1:34 PM, Kuno Woudt <kuno@frob.nl> wrote:

> Hello,
>
>
> On 07/10/2012 06:06 PM, Markus Lanthaler wrote:
>
>> To turn this into linked data the ids would somehow have to be turned
>>> into full IRIs.  So fcbcdc39-8851-4efc-a02a-**ab0e13be224f, which is a
>>> recording would need to become:
>>>
>>> http://musicbrainz.org/**recording/fcbcdc39-8851-4efc-**
>>> a02a-ab0e13be224f#_<http://musicbrainz.org/recording/fcbcdc39-8851-4efc-a02a-ab0e13be224f#_>
>>>
>>> And abcd76db-7d5f-3eb7-b386-**051c97bfe2e4 should become
>>>
>>> http://musicbrainz.org/**release/abcd76db-7d5f-3eb7-**
>>> b386-051c97bfe2e4#_<http://musicbrainz.org/release/abcd76db-7d5f-3eb7-b386-051c97bfe2e4#_>
>>>
>>
>> ... and you definitely don't wanna include the full (or at least a
>> relative)
>> IRI in the JSON document? Any specific reasons for that?
>>
>
> There is lots of existing software out there which expects just the bare
> identifiers (our customers and other users of either the database or the
> existing xml webservice).
>

I agree. I apologize in advance for the slight digression: here is another
story that relates to what I was chatting about with Manu on IRC earlier.
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). 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. 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. 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].

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.

Steph.

[1] https://groups.google.com/d/msg/arc-dev/7UXELn5MErk/0G3ytZnuAzwJ


>
> For example if you were writing a media player in python trying to get
> information on an album, you would do something like this:
>
> >>> import mutagen
> >>> f = mutagen.File ("14. BUT (KOZM_ Remix).mp3")
> >>> f["TXXX:MusicBrainz Album Id"].text[0]
> u'8ea5b78d-bda6-497a-b191-**2650b8e20ba0'
>
> Now you have the identifier for an album/release, if you want to send
> people to our website with that, you would construct:
>
> http://musicbrainz.org/**release/8ea5b78d-bda6-497a-**b191-2650b8e20ba0<http://musicbrainz.org/release/8ea5b78d-bda6-497a-b191-2650b8e20ba0>
>
> Or if you wanted to look up metadata in our webservice you would construct:
>
> http://musicbrainz.org/ws/2/**release/8ea5b78d-bda6-497a-**
> b191-2650b8e20ba0<http://musicbrainz.org/ws/2/release/8ea5b78d-bda6-497a-b191-2650b8e20ba0>
>
> If you wanted to get 500x500 front cover art image you would get:
>
> http://coverartarchive.org/**release/8ea5b78d-bda6-497a-**
> b191-2650b8e20ba0/front-500.**jpg<http://coverartarchive.org/release/8ea5b78d-bda6-497a-b191-2650b8e20ba0/front-500.jpg>
>
> The cover art archive is actually hosted by the internet archive, so this
> also works:
>
> http://archive.org/details/**mbid-8ea5b78d-bda6-497a-b191-**2650b8e20ba0<http://archive.org/details/mbid-8ea5b78d-bda6-497a-b191-2650b8e20ba0>
>
> If you wanted to have a look at some listening statistics, I think
> http://last.fm/mbid/8ea5b78d-**bda6-497a-b191-2650b8e20ba0<http://last.fm/mbid/8ea5b78d-bda6-497a-b191-2650b8e20ba0>should work (
> last.fm is currently having issues, so that is not online right now).
>
> Or if you wanted to see if the artist has been played on the BBC radio
> recently, you would get the artist identifier from the file and construct:
>
> http://www.bbc.co.uk/music/**artists/455641ea-fff4-49f6-**
> 8fb4-49f961d8f1ac<http://www.bbc.co.uk/music/artists/455641ea-fff4-49f6-8fb4-49f961d8f1ac>
>
> So, in general there are many websites, services and applications which
> use just these bare identifiers.  Because of this, users of our webservice
> want to get just the identifier, so they can construct all these urls.
>
>  I fear this is a transformation which cannot be described in a
>>> "@context", is that correct?  Any suggestions?
>>>
>>
>> That's true. We discussed that some time ago [1] but decided to not
>> support
>> it at this point in time. If you could give us some more insights on why
>> you
>> don't use an IRI directly we might reopen that issue.
>>
> >
> > [1] https://github.com/json-ld/**json-ld.org/issues/108<https://github.com/json-ld/json-ld.org/issues/108>
>
> MusicBrainz is not a new project (about 10 years old now I guess), we have
> a large community of users, customers, etc.. who all use and store these
> identifiers in their own databases, schemas, etc..
>
> So, although the JSON representation of this data in our webservice is
> new, the data/graph itself is not.
>
> -- kuno / warp.
>
>