RE: revising Extension Mechanism

> this approach violates URI Opacity[1]

The URI opacity recommendation applies primarily to clients. 
A client should not assume that anything can be inferred from the structure and content of a URI string. 

However, there is no reason that URI creation should not include some structure, if it helps somewhere in the system. 
It is quite reasonable to use rules around production of URIs to assist in delegation, and clash avoidance. 
If this results in URIs that are more memorable than otherwise, then great. 
There is generally no harm done by making URIs memorable. 

The tricky bit with URIs is that the /// structure only supports a mono-hierarchy. 
Thus any designed structure privileges one view of the organization of the URI set. 
But that is OK - the URI opacity argument can be interpreted to say that 'information inferred from the URI structure is incomplete' and REST tells you to inspect the resource representation to find out more about the thing denoted by the URI. 

Simon Cox 


-----Original Message-----
From: ☮ elf Pavlik ☮ [mailto:perpetual-tripper@wwelves.org] 
Sent: Monday, 20 October 2014 8:50 AM
To: public-vocabs@w3.org Vocabs
Cc: martin.hepp@ebusiness-unibw.org; pieter@irail.be; Richard.Wallis@oclc.org
Subject: revising Extension Mechanism

Hello,

Currently documentation recommends using '/' for 'extending' schema.org http://schema.org/docs/extension.html


for example:

Person/Engineer/ElectricalEngineer
musicGroupMember/leadVocalist

To my understanding this approach violates URI Opacity[1] and doesn't allow dereferencing terms 'extended' in such way.

In one of previous emails I suggested one of possible alternatives, to instead of schema:Action/HugAction use multiple types schema:Action ex:HugAction

JSON-LD:
{
  "@context": ["http://schema.org", { "ex": "http://example.net/#" }]
  "@type": ["Action", "ex:HugAction"],
  ...
}

Currently http://bibliograph.net looks like nice example of extension [2]. Maybe some of numerous 'medical' schemas could also become eventually some kind of medigraph?

Also GoodRelations stays in sync and also could give good example of providing more advanced features on top of those directly incorporated in schema.org

Besides that some of the people partcipating in Social WG might consider leveraging WebSchemas work. To my understanding it would require solid extension mechanism to accommodate for example needs of Activity Streams
2.0 Vocabulary[3] Possibly a topic for face 2 face meeting during TPAC[4] ?

Last but not least http://vocab.gtfs.org looks like another vocab which could potentially extend schema.org. GTFS started as 'Google Transit Feed Specification' and I hope new RDF vocab could also work with Rich Snippets etc.

I realize that everyone stays super busy and we may not find enough cycles to give this topic enough attention. Still maybe worth trying to start with gathering feedback and ideas?

Cheers!

[1] http://www.w3.org/TR/webarch/#uri-opacity

[2] http://www.slideshare.net/rjw/extending-schemaorg

[3]
http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-vocabulary.html

[4] https://www.w3.org/wiki/TPAC2014/SessionIdeas#Schema.org_and_Social_WG

Received on Sunday, 19 October 2014 22:33:19 UTC