RE: revising Extension Mechanism

> Structured URIs are often manifestations of tight-coupling with a specific technology stack

Often, but not always. Certainly this was historically the case, but I think we are getting more sophisticated now. 

> It also tends to limit the evolution of the data model as new use cases emerge.

Yes - that is the issue I'm referring to with my comment about mono-hierarchy. A structure does commit you to a single hierarchy. However, I disagree that it will (necessarily) limit evolution. If you want to break out of the original hierarchy, then you are at liberty to treat them as opaque. 

Simon 

-----Original Message-----
From: Young,Jeff (OR) [mailto:jyoung@oclc.org] 
Sent: Tuesday, 21 October 2014 5:54 AM
To: Cox, Simon (L&W, Highett); perpetual-tripper@wwelves.org; public-vocabs@w3.org
Cc: martin.hepp@ebusiness-unibw.org; pieter@irail.be; Wallis,Richard
Subject: RE: revising Extension Mechanism

I disagree that this is primarily a client-side concern. 

Structured URIs are often manifestations of tight-coupling with a specific technology stack, which makes it hard to replace. It also complicates data cleanup. It also tends to limit the evolution of the data model as new use cases emerge.

Jeff

> -----Original Message-----
> From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au]
> Sent: Sunday, October 19, 2014 6:33 PM
> To: perpetual-tripper@wwelves.org; public-vocabs@w3.org
> Cc: martin.hepp@ebusiness-unibw.org; pieter@irail.be; Wallis,Richard
> Subject: 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 Tuesday, 21 October 2014 00:08:08 UTC