webfinger-aware URL scheme

[Michiel de Jong]

Hi! we were just talking in #json-ld on freenode. we need a way to uniquely and unambiguously refer to 'the value of favSandwich in the sandwiches category on mic...@unhosted.org's remoteStorage'. and to resolve such a referral, you would have to do a webfinger lookup for mic...@unhosted.org, find the link with rel 'remoteStorage', fill in {category} in the template, and then use the resulting http url.

options proposed:

rww:mic...@unhosted.org/sandwiches#favSandwich
acct:mic...@unhosted.org/sandwiches#favSandwich
rs:mic...@unhosted.org/sandwiches#favSandwich

abbreviations:
rww = read-write web
acct = account
rs = remoteStorage

I prefer 'rww', to indicate that doing linked data on remoteStorage /is/ read-write web, and not a competing spec or anything. we are largely the same people with largely the same goal in the unhosted cg and in the rww cg.

so in myfavouritesandwich we would then use:

{
  @context: 'https://github.com/unhosted/website/wiki/Categories#sandwiches',
  @id: 'rww:mic...@unhosted.org/sandwiches/favSandwich',
  ingredients: ['bacon', 'cheese']
}

and whoever receives this data object will be able to
1) if they already support https://github.com/unhosted/website/wiki/Categories#sandwiches process this as a favourite sandwich
2) if not, make a developer read https://github.com/unhosted/website/wiki/Categories#sandwiches and implement support for it

but, and this is what i finally came to understand today thanks to Melvin's and everybody else's tireless attempts to explain this to me, /without/ referring to the source code of the original myfavouritesandwich application. we have separated data documentation from code documentation. so that's another useful step in separating applications from data i think.

i was going to cross-post this to both the unhosted and the rww mailing lists, because the term 'read-write web' refers principally to that community group, but cross-posts are always so awkward so instead i'll post it to unhosted and post a link to the thread on the rww one. if they feel that this would be a confusing use of the abbreviation 'rww' then we will pick one of the other options. but i do think it is what read-write web is about, and that it would be the best, most accurate choice. so we'll see what they say. :)


Cheers!
Michiel

[Melvin Carvalho]

On 16 January 2012 23:07, Michiel de Jong <mic...@unhosted.org> wrote:
> Hi! we were just talking in #json-ld on freenode. we need a way to uniquely
> and unambiguously refer to 'the value of favSandwich in the sandwiches
> category on mic...@unhosted.org's remoteStorage'. and to resolve such a
> referral, you would have to do a webfinger lookup for mic...@unhosted.org,
> find the link with rel 'remoteStorage', fill in {category} in the template,
> and then use the resulting http url.
>
> options proposed:
>
> rww:mic...@unhosted.org/sandwiches#favSandwich
> acct:mic...@unhosted.org/sandwiches#favSandwich
> rs:mic...@unhosted.org/sandwiches#favSandwich
>
> abbreviations:
> rww = read-write web
> acct = account
> rs = remoteStorage
>
> I prefer 'rww', to indicate that doing linked data on remoteStorage /is/
> read-write web, and not a competing spec or anything. we are largely the
> same people with largely the same goal in the unhosted cg and in the rww cg.
>
> so in myfavouritesandwich we would then use:
>
> {
>   @context:
> 'https://github.com/unhosted/website/wiki/Categories#sandwiches',
>   @id: 'rww:mic...@unhosted.org/sandwiches/favSandwich',
>   ingredients: ['bacon', 'cheese']
> }

What about

{
@context:
'https://github.com/unhosted/website/wiki/Categories#sandwiches',
@id: 'mailto:mic...@unhosted.org,
favSandwich : ingredients: ['bacon', 'cheese']

[Thad Guidry]

{
 @context:
'https://github.com/unhosted/website/wiki/Categories#sandwiches',
 @id: 'ns:mic...@unhosted.org,

 favSandwich : ingredients: ['bacon', 'cheese'] 

Isn't it just YOUR name ? or account name ? equivalent to your particular namespace ? sooo.. ns

--
-Thad
http://www.freebase.com/view/en/thad_guidry

[Michiel de Jong]

i think the assumption that a key-value pair has a subject is too strong, and the assumption that the data owner, as a person, is the subject of the data, is even stronger, and will mostly be inaccurate. maybe i asked the wrong question.

so for @context, it seems clear that we want to point to our wiki from inside each key-value pair. it's a bit of a waste of bytes - it would be nicer if we could do this only once per category, and have it apply to all key-value pairs contained therein, but for now i think it's good enough.

let's leave the topic of @id and instead look at pointers, first. For instance in Libre Docs we have a documents list, which is a list of documents. Some of these will be on your own storage, while others will be on the public storage of other people. maybe you even have documents in there that point to a normal http resource (e.g. an image that you hotlink in a text doc). So for these i would then use:

* #hash for documents on the same category of the same user.
* /category#hash for documents on other categories of the same user.
* //user@host/public#hash for documents that other users shared with you
* http://host/path for external http resources.

here, we haven't had to name our protocol, since we're only referencing resources that are local to it.

about things like SPARQL, i don't think we need it. I think easy-to-achieve and big steps forward here are:

1) add a comment with a link to documentation inside your data, just like you do in your source code. this is the @context field.
2) whenever  you point to another key-value pair, use the standard URL format. Just like in C it's best practice to use proper pointers and not integers or other self-invented schemes, whenever your data is pointing to other data. that way the references you make can be resolved even without referring to your documentation.

I'll try to apply this to the 'sandwiches' and 'documents' categories. Does that make sense?


Cheers!
Michiel

[Kingsley Idehen]

Yes!

+1

Kingsley

>> and whoever receives this data object will be able to
>> 1) if they already support
>> https://github.com/unhosted/website/wiki/Categories#sandwiches process this
>> as a favourite sandwich
>> 2) if not, make a developer read
>> https://github.com/unhosted/website/wiki/Categories#sandwiches and implement
>> support for it
>>
>> but, and this is what i finally came to understand today thanks to Melvin's
>> and everybody else's tireless attempts to explain this to me, /without/
>> referring to the source code of the original myfavouritesandwich
>> application. we have separated data documentation from code documentation.
>> so that's another useful step in separating applications from data i think.
>>
>> i was going to cross-post this to both the unhosted and the rww mailing
>> lists, because the term 'read-write web' refers principally to that
>> community group, but cross-posts are always so awkward so instead i'll post
>> it to unhosted and post a link to the thread on the rww one. if they feel
>> that this would be a confusing use of the abbreviation 'rww' then we will
>> pick one of the other options. but i do think it is what read-write web is
>> about, and that it would be the best, most accurate choice. so we'll see
>> what they say. :)
>>
>>
>> Cheers!
>> Michiel

--

Regards,

Kingsley Idehen
Founder& CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Thad Guidry]

Makes more sense... not quite how I would do things, but that's OK.

BTW, after reading this, I see that @Context is actually more of the Namespace than anything else.  That's exactly what Namespaces do, they give some "context" or " name" OF THE "space" or "domain" that your dealing with.

On Tue, Jan 17, 2012 at 4:45 AM, Michiel de Jong <mic...@unhosted.org> wrote:

i think the assumption that a key-value pair has a subject is too strong, and the assumption that the data owner, as a person, is the subject of the data, is even stronger, and will mostly be inaccurate. maybe i asked the wrong question.

so for @context, it seems clear that we want to point to our wiki from inside each key-value pair. it's a bit of a waste of bytes - it would be nicer if we could do this only once per category, and have it apply to all key-value pairs contained therein, but for now i think it's good enough.

let's leave the topic of @id and instead look at pointers, first. For instance in Libre Docs we have a documents list, which is a list of documents. Some of these will be on your own storage, while others will be on the public storage of other people. maybe you even have documents in there that point to a normal http resource (e.g. an image that you hotlink in a text doc). So for these i would then use:

Documents is clearly a category then (which we already have, cool)... and like FluidInfo has namespaces, which is a concrete ownership like the one reserved for you still: /datahope/docs , then whatever prefixing others are comfortable with should suffice as you list here (and I get what your trying to accomplish, simplified resource pointers, I get that, and that's fine.  RDF is how academics handle this, Resource Description Framework...same thing, giving pointers to resources and describing them somewhere :

* #hash for documents on the same category of the same user.
* /category#hash for documents on other categories of the same user.
* //user@host/public#hash for documents that other users shared with you
* http://host/path for external http resources.

here, we haven't had to name our protocol, since we're only referencing resources that are local to it.

about things like SPARQL, i don't think we need it. I think easy-to-achieve and big steps forward here are:

1) add a comment with a link to documentation inside your data, just like you do in your source code. this is the @context field.

Oh boy, you lost me on 1 because now your breaking your own rules... hmm, perhaps they are not defined well enough here for comments and how they will work ?...I'll wait for more info to make a judgement.

 

2) whenever  you point to another key-value pair, use the standard URL format. Just like in C it's best practice to use proper pointers and not integers or other self-invented schemes, whenever your data is pointing to other data. that way the references you make can be resolved even without referring to your documentation.

I'll try to apply this to the 'sandwiches' and 'documents' categories. Does that make sense?

 

If you can apply this and give examples, that would help...pictures are worth a thousand words

 

--
-Thad
http://www.freebase.com/view/en/thad_guidry