- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Mon, 30 Mar 2015 11:53:46 +0200
- To: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
- Cc: W3C Web Schemas Task Force <public-vocabs@w3.org>
- Message-ID: <CAKaEYhJz8jzwwB8Ud8CAr39LMpqHgx7ip44inUrDoJK=W+f7tQ@mail.gmail.com>
On 30 March 2015 at 10:31, ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org> wrote: > Hello, > > In Social WG we currently only use JSON-LD as normative serialization. I > just suggested that instead of defining tons of inverse properties in > vocabulary(ies), we can simply define aliases for them in JSON-LD context. > http://www.w3.org/TR/json-ld/#reverse-properties > > Myself I already do it on my website which uses schema.org as base and > extends it with other vocabularies. Currently I define in JSON-LD @context. > > "attendeeIn": { "@reverse": "attendee" } > > And as of today I start adding > > "authorOf": { "@reverse": "author" } > "subjectOf": { "@reverse": "about" } > > ( leaving out now issue with not using "@type": "@id" ) > > Would you see it making sense to maintained list of such recommended > names for properties when used as inverse? > > Example of one from The PROV Ontology > http://www.w3.org/TR/2013/REC-prov-o-20130430/#inverse-names-table > I've had this issue also in the past where I have a link from one thing to the other, but then I want to start at one place and link backwords. I didnt know you could use @reverse in JSON LD in this way, that's a neat finding. People I know that have experience with modeling and ontologies tell me it's generally a bad idea to create terms for both a relation and it's inverse. While it may solve an initial pain point, what I am told it that it complicates code bases further along. I dont know if this applies also to your aliasing use case, but I've been told in the past, to try to pick one direction and use that, it may be something to note. > > Cheers! > >
Received on Monday, 30 March 2015 09:54:14 UTC