Re: ActivityStreams Schema: Hierarchy of Types

On Wed, Nov 05, 2014 at 08:38:27AM +0000, Owen Shepherd wrote:
> 
> > On 5 Nov 2014, at 05:16, James M Snell <jasnell@gmail.com> wrote:
> > 
> > While I certainly agree that a vocabulary of this sort will be
> > necessary (let's call it the "Social Object Vocabulary" to
> > differentiate it from the "Activity Vocabulary"), this becomes a very
> > slippery path... if we're not careful, we'll just end up rehashing the
> > same ground covered by other efforts (vcard, foaf, schema.org, org
> > ontology, etc). As much as possible, we ought to be looking at these
> > existing vocabularies before attempting to hash out anything else.
> > 
> > For instance, we simply don't need an as:Person when we already have
> > things like foaf:Agent, schema.org/Person, vcard:Individual,
> > prov:Agent, and likely many others. One thing that would likely help
> > is to start documenting the abstract generalized concepts then mapping
> > those to the existing vocabularies, we can then see where the gaps
> > exist. I've started working on that here:
> > 
> > https://www.w3.org/wiki/Socialwg/Social_Vocabulary
> > 
> > - James
> 
> I’m in favour of us defining our own types for the core elements because
> Requiring people to remember that its’ foam:Person and org:Organization and … will quickly get confusing. The core types we need should be part of the specification, whether that be the AS2 specification or some “AS2 Base Schema”
> We have the expressive power of Owl to say that 
> “as:Person”: {
>     “owl:equivalentClass”: [“vcard:Individual”, “prov:Person"]
> }
> The same argument could be made for as:Object (vs foaf:Thing, etc), yet we persist with as:Object
> 
> Put simply, non JSON-LD processors shouldn’t need to know about card or foaf or schema.org <http://schema.org/> unless they specifically wish to do so (i.e. they wish to take advantage of some features from there)
> 
> I am not at all opposed to us utilising other schema, especially widely deployed ones like vcard, where appropriate, but you shouldn’t need to leaf through 7 different vocabularies in order to get a basic social network working. 
> 
> ActivityStreams should cover the basics, and define how this maps with the “extended vocabulary"
> 
>  Owen

I'd see creating a standardized JSONLD context as purer way to achieve accessibility for dumb tools. How would
creating actual types allow equivalence with the specs ActivityStream wanted to draw from? This project doesn't
sound like it's choosing vocabs- it implies the creation of new types/namespaces for the convience of very dumb
tooling that wants to be type-blind, while ignoring interoperability with actual real tools.

Received on Friday, 7 November 2014 23:11:39 UTC