Open Locative Media standard – who/what is it for?

Home Forums Technology Open Locative Media standard – who/what is it for?

Viewing 15 posts - 1 through 15 (of 30 total)
Author Posts
#42775
Josh Kopeček
Josh Kopeček
Participant

Carrying on from the discussions elsewhere, I wanted to raise the point here about who and what this is for.

  • IMHO, this is first and foremost for artists.
  • Secondly it’s for archival, starting with the earliest pieces first. Interchange between platforms is a ‘nice to have’ but for me is a separate problem which would be solved as a result of creating the format in the first place.
  • Thirdly this standard should act as a descriptor for locative media projects. By this I mean that it should be a language which can describe *any* project, starting with the earliest pieces first.

Discuss…

#42838
Geert Vermeire
Geert Vermeire
Participant

Hi Josh, I can find myself in what you write, although I would open the term artists to all creatives (also writers, journalists, radio, heritage experts, historians, environmentalists, activists, community workers, educators, scientists, researchers and all cultural professionals that look for creative location-based ways to intermediate or approach their field of expertise).

From the wlc point of view is the archival aspect as well a priority, preserving the past, but also the present. Much locative media platforms have a short life span, and keep coming and going, to have their collections secured for a future is as important as looking back.
Many of the earliest pieces were very individual, in early 2000. It is worth delving into this prehistory. Locative Media Archeology.
If we go to a larger scope it would be good to explore (European) funding, any partners out there?

#42848
Josh Kopeček
Josh Kopeček
Participant

@geert absolutely behind this. I think we agree on the scope of the enquiry. Can we each investigate the possibilities for a set of funded research on the topic? I know a few people who might be interested in researching this topic in the long-term.

Who else is +1 for this?

#42904
Hamish Sewell
Hamish Sewell
Participant

I think ‘artists’ is too narrow here and I lean more towards Geert’s interpretation of who it’s for. Beside, I wonder if it really matter who it’s designed for? Create the opportunity to work more fluidly across platforms, whether by dint of their being a system that is operable across platforms, or through the broader pick up of this system, and I suspect people will come; whether artists or archivists, commissioning agents or conservators.

#42905
Hamish Sewell
Hamish Sewell
Participant

Pondering @Josh your idea of a signature to this de-coupled work. If it’s in the name of copyright, then that’s already internationally recognised, I think, and easy to implement. Is it rather a signature for a producer/artist or a suite of site specific works perhaps? Can there be some sort of indelible imprint/signature/watermark on the work – a map, no doubt – that transfers across different platforms? And if so, then who gets to ‘mark’ it?

#42918
Josh Kopeček
Josh Kopeček
Participant

@Hamish you actually wrote the part about the ‘signature’ – it’s your idea, not mine!

If you’re talking about a plaintext format, there’s no possibility of having a ‘signature’ unless we have a central database/repository (such as WLC). What is possible is having a set of ‘authors’, but this would be part of the standard.

In terms of legality, we should definitely employ a space for a licence so that people can stipulate on what terms they are distributing their work – MIT, Creative Commons, GPL, Private, Unlicensed etc.

Separately, regarding the question of who it’s for, I think this is essential – possibly more so the set of use cases, for us to be in agreement on why we’re doing this.

#42940
Hamish Sewell
Hamish Sewell
Participant

@Josh. I wrote it! Seems a long time ago in the maze of communication. Ok.
Is plaintext a given here?
License, yes, I agree, though I’m no expert on this, but it seems entirely appropriate that producers, commissioners, artists – those who rightfully own this work and have put in the hard yards – have the opportunity for some sort of ownership and/or attribution. Regarding ‘who’s it for’ I think there needs to be a lot more discussion around this and I’m curious to hear your thoughts.

#42975
Babak Fakhamzadeh
Keymaster

Ah, sorry about misattributing the source of the line on the signature.

@Hamish: If you’re questioning whether we should consider not using plaintext, I’m very strongly against not using plaintext. Plaintext is the format that can always be read by anything.

@Hamish, @Josh: Yes, WLC, or any centralised repository, could function as a kind of issuing authority for unique signatures, but this can’t really be a requirement as part of the standard, as this prevents independent portability.
In addition, the purpose of this signature would need to be defined, and I’m not yet clear on what its purpose is.

In short, it then seems to me that the idea of this signature should be dropped.

On rights; it makes sense to allow rights to be set for each referenced file, individually, as well as for the piece as a whole.

On use cases: More clearly defined use cases are great to have.

#42980
Josh Kopeček
Josh Kopeček
Participant

-1 for signature – if you’re thinking along the lines of DRM, as @babak mentions, it prevents portability, and we’re all for an open standard.

Plaintext (yml, json, xml etc.) is essential. It doesn’t necessarily have to be tied to a particular format, all the formats I just mentioned (yml, json, xml) are almost completely interchangeable.

I think we should look to other standards such as GeoJSON or KML, which already have a remit (albeit pretty unspecific) for attaching metadata to locations.

I will try to find some time to do work on specific case studies. Feel free to interpose here.

#42985
Josh Kopeček
Josh Kopeček
Participant

One thought – what about media storage?

This open format simply describes the metadata associated with a given work. Is it the onus of the person to create a permanent storage space? I quite often come across dead dropbox/google drive links. I don’t think there’s any way we could enforce this – just make recommendations, but it’s such an integral part of locative media that we must think very carefully about it.

One solution might be describing a container format with extended metadata, like mp4, where everything is bundled together. It could be backwards compatible with e.g. .zip. The only issue here is corruption, but compressed formats works pretty well with badly corrupted files.

#43004
Babak Fakhamzadeh
Keymaster

On how to reference media; it doesn’t seem ideal to allow for inclusion of files within the context of the standard as this quickly could see overall file size explode.

@josh: I’m not sure I follow your reference to a container format.

I’d say that, yes, it would be the author’s responsibility to find a place to host files. Though, I suppose, it could also be allowed for file references to not be URIs, but also be referenced as relative to the open standard file.

So, it seems we’re leaning towards ditching a signature, yes?

#43010
Hamish Sewell
Hamish Sewell
Participant

@Babak, Ok, I’m happy to drop signatures – reluctantly!

@Josh, other formats to KML – are there advantages to each different format? And how much is known about building transportable formats from out of them?

Vis archiving. Doesn’t an open standard now allow for projects to expand significantly: entire cities via on map? Too big? Archiving might be a useful point from which WLC could negotiate funding vis a library etc – or not?

#43033
Josh Kopeček
Josh Kopeček
Participant

Some examples of formats, with the same data in each format.

yaml/yml

type: oml
author: josh
title: some archivable soundwalk
data:
- name: Hello!
location: [12.345,13.456]
metadata:
- colour: green
type: circle
radius: 13
- name: Another
location: [12.345,13.456]
metadata:
- colour: blue
type: circle
radius: 14
<code></code>

json

{
"type": "oml",
"author": "josh",
"title": "some archivable soundwalk",
"data": [
{
"name": "Hello!",
"location": [
12.345,
13.456
],
"metadata": [
{
"colour": "green"
}
],
"type": "circle",
"radius": 13
},
{
"name": "Another",
"location": [
12.345,
13.456
],
"metadata": [
{
"colour": "blue"
}
],
"type": "circle",
"radius": 14
}
]
}
<code></code>

xml

<type>oml</type>
<author>josh</author>
<title>some archivable soundwalk</title>
<data>
<name>Hello!</name>
<location>12.345</location>
<location>13.456</location>
<metadata>
<colour>green</colour>
</metadata>
<type>circle</type>
<radius>13</radius>
</data>
<data>
<name>Another</name>
<location>12.345</location>
<location>13.456</location>
<metadata>
<colour>blue</colour>
</metadata>
<type>circle</type>
<radius>14</radius>
</data>

Regarding the container format.
I’m going to completely disregard what I said, but first I’ll explain what I meant.
mp4 is a container format – that means it doesn’t matter so much what you put in it – actually the audio/video can be encoded in a variety of different ways, and the metadata is pretty extensive.

However, it’s a binary format, and ours would need to be as well in order to include any media so it precludes plaintext. So a container format is out the window.

We come back to the problem of this ‘floating media’, and hosting the media itself. If it’s the responsibility of the creator, then there’s an unnecessary onus on them to find a long-term solution. There’s also the cost etc. Providing a library (along the lines of archive.org) which could be WLC long-term. I have to say our media hosting costs are still pretty negligible, even after all this time. But if you introduce video to that mix it all goes out the window.

To recap:
descriptive plaintext format +1
signatures -1
container -1
long-term media hosting – to be discussed

#43039
Hamish Sewell
Hamish Sewell
Participant

I find the specific examples and generic examples helpful Josh. I wonder to what extend we could extrapolate and look at what broader opportunities a standard might open up: creative dossiers for sound artists, locative projects showcased on some sort of shopfronts etc. I see you took this down and appreciate that this might be a bridge too far at this point, but still I think it’s relevant.
On the archive front, while mp4 is useful, it will not work with plaintext. So there’s the dilemma of what formats an artist archives their work with. I don’t quite get this connection, nor the difference between archiving and transferring. Is this a dilemma if they simply want to transfer from one platform to another without video? You’re suggesting @Josh WLC might host an archive portal, hub but that video creates significant costs. Would WLC even consider playing such a role @Babak? Perhaps video needs to come with a cost. I think a broad conversation is nigh so we’re all on the same page.

#43045
Josh Kopeček
Josh Kopeček
Participant

Feel free to add other use cases, but make sure they are completely distinct/unique. I only removed a couple of use cases because they were too similar or covered by the other ones.

Archives: it’s not the problem of what format an artist works in, it’s the longevity of the storage.

For example: there’s a soundwalk which is stored on mp3 players somewhere in someone’s loft. They decide to create a plaintext representation (.olm file) and upload that to WLC, at the same time copying those mp3 files to dropbox and adding the links into the .olm file. One day they decide to cancel their dropbox account because upmyfile.com has a new offer on, forgetting to transfer the files. The files don’t get updated on WLC and the walk is essentially defunct because none of the media is available.

Essentially we have two conflicting requirements:
1. easily readable plaintext representations of the metadata for a work
2. long-term storage of media associated with said works

Viewing 15 posts - 1 through 15 (of 30 total)
  • You must be logged in to reply to this topic.