Re: Locating file- and directory-specific metadata (Was: Re: Spec review request: CSV on the Web)

That was a (nearly) throwaway suggestion. The Link format does have the virtue of being defined, but it isn't something I'd want to perpetuate too much…

Cheers,


> On 24 May 2015, at 5:49 am, Jeni Tennison <jeni@jenitennison.com> wrote:
> 
> Hi Dan,
> 
> The format Mark suggested is the format of the value of the Link HTTP header, so (a) it’s already defined and (b) the processors we care about are going to need to be able to parse it anyway.
> 
> Jeni
> --  
> Jeni Tennison
> http://www.jenitennison.com/
> 
> On 23 May 2015 at 17:16:04, Dan Brickley (danbri@google.com) wrote:
>> On Sat, 23 May 2015 12:40 Jeni Tennison wrote:
>> 
>> Hi,
>> 
>> I’m a little reluctant to use Web Host Metadata as it would require
>> processors to incorporate XML parsers.
>> 
>> Defining a text-based .well-known format containing patterns is feasible.
>> What if we did that and said that if such a file were missing
>> implementations should proceed as if there were a file that contains some
>> given patterns, ie:
>> 
>> <{path}-metadata.json>; rel="describedBy"; type="application/csvm+json”
>> <{path}/../metadata.json>; rel="describedBy"; type="application/csvm+json"  
>> 
>> 
>> <{path}-metadata.json> "application/csvm+json” .
>> 
>> ... Would be ntriples, nearly.
>> 
>> I'm a bit squeamish about inventing yet another metadata format. Shouldn't
>> we at least use comma separated rows instead of semicolons? Or JSON?
>> 
>> Dan
>> 
>> 
>> That would retain the ease of use in an environment where access to
>> .well-known was tricky while allowing publishers who want to have more
>> control over their URL space (but still have no access for setting Link
>> headers) to override the default behaviour.
>> 
>> Cheers,
>> 
>> Jeni
>> --
>> Jeni Tennison
>> http://www.jenitennison.com/
>> 
>> On 20 May 2015 at 01:35:40, Mark Nottingham (mnot@mnot.net) wrote:
>>> 
>>>> On 20 May 2015, at 9:44 am, Yakov Shafranovich wrote:
>>>> 
>>>> On Tue, May 19, 2015 at 1:16 PM, Jeni Tennison wrote:
>>>>> On 19 May 2015 at 07:52:01, Mark Nottingham (mnot@mnot.net) wrote:
>>>>> 
>>>>> The reason that I thought this worthy of TAG discussion is because it
>> illustrates a
>>> situation where file- and directory-specific well known locations would
>> be very useful.
>>> This might be a need that arises in other cases, so it would be helpful
>> for the community
>>> to have the best-practice way of addressing the requirement spelled out.
>> This is particularly
>>> the case if the right solution is .well-known, as .well-known is
>> currently described
>>> as being for "site-wide metadata", not metadata for individual files.
>> Plus it's always
>>> useful to test best practice guidance against real use cases.
>>>>> 
>>>> 
>>>> I would like to add that RFC 6415 provide a mechanism for
>>>> resource-specific metata, although IMHO this is clunky. This would use
>>>> templates defined in a host-meta file which would be placed in the
>>>> ",well-known" directory.
>>> 
>>> WHD is one way to do it, but it might be simpler to just define a
>> .well-known that indicates
>>> what the convention for per-directory / per-file metadata is; e.g.,
>>> 
>>> /.well-known/metadata-locations
>>> 
>>> contains
>>> 
>>> —%<—
>>> <{path}.md>; rel=foo
>>> —>8---
>>> 
>>> where the contents of is a URI template (<>),
>>> so that a client would know that the metadata for
>>> 
>>> /foo/bar.json
>>> 
>>> is at
>>> 
>>> /foo/bar.json.md
>>> 
>>> 
>>> Another way to do it would be to put the CSV in a package / wrapper
>> format that contains the
>>> metadata.
>>> 
>>> 
>>> Cheers,
>>> 
>>> 
>>> --
>>> Mark Nottingham https://www.mnot.net/
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Sunday, 24 May 2015 01:59:43 UTC