Fwd: Re: List of commonly used property names when used as *inverse*?

Relevant to at least two WG Issues and IG Vocabulary TF in general
* JSON-LD contexts https://www.w3.org/Social/track/issues/36
* as:Link https://www.w3.org/Social/track/issues/14


-------- Forwarded Message --------
Subject: Re: List of commonly used property names when used as *inverse*?
Resent-Date: Mon, 30 Mar 2015 10:41:25 +0000
Resent-From: public-vocabs@w3.org
Date: Mon, 30 Mar 2015 12:40:31 +0200
From: Bernard Vatant <bernard.vatant@mondeca.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
CC: W3C Web Schemas Task Force <public-vocabs@w3.org>, Tommie Usdin
<btusdin@mulberrytech.com>

2015-03-30 11:53 GMT+02:00 Melvin Carvalho <melvincarvalho@gmail.com>:

>
> <http://www.w3.org/TR/2013/REC-prov-o-20130430/#inverse-names-table>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.
>>
>
+1

Take just skos:broader and skos:narrower. Some applications rely on the
former, others on the later, some infer the inverse property, some not, so
the same semantics come in too many possible syntaxes. Not all applications
have a built-in reasoner  ...

I've always kept in mind, and fortunately unearthed the paper [1] a lively
and definitive presentation of this kind of issues by Tommie Usdin (in cc
for the record) at Extreme Markup 2002.

Excerpt :

If you give me several ways to encode the same content and don’t give me
guidance on what each of them means, you have *not* given me increased
expressive power, you have given me:

   - increased effort to encode (because I have to decide which method to
   use; I don’t want to think about that; I want to think about my content!)
   - increased likelihood that the recipients of my content will fail to
   use it or, worse, misinterpret it
   - reduced ability to add future complexity to the system by adding
   meaningful alternate encodings (by using them up in meaningless ways)
   - increased complexity of all down-stream applications that need to
   process the content.

This was in the scope of XML content, but seems definitely still relevant
here.

[1]
http://conferences.idealliance.org/extreme/html/2002/Usdin01/EML2002Usdin01.html


-- 

*Bernard Vatant*
Vocabularies & Data Engineering
Tel :  + 33 (0)9 71 48 84 59
Skype : bernard.vatant
http://google.com/+BernardVatant
--------------------------------------------------------
*Mondeca*
35 boulevard de Strasbourg 75010 Paris
www.mondeca.com
Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>
----------------------------------------------------------