Re: Property "geographic identifier" in LOCN

Hi Raphael,

maybe we can ask the question the other way around: Why would you prefer 
to reuse single relation and class names from different sources?

This will force you to import many vocabularies/ontologies which will 
create unintended logical consequences. Additionally, you really do not 
know whether those relations and classes are really the same. Many of 
them are under-specific to a degree where you can just guess.

Sven is not saying you should redo everything from scratch (e.g., your 
own GeoSPARQL) but making a standard that imports single relations and 
classes from multiple sources and hoping that they somehow stick 
together seems odd to me.

For instance, I would be very surprised if the US government would give 
up their own schema and use FAOF to annotate Persons.

> Do you have data that
>> backups this statement that "practice shows that groups favor new
>> developments"? My experience is the other way around, i.e. successful
>> vocabularies re-use small vocabularies.

Given Svens position at JRC, I guess this is his daily business. From my 
perspective. We are currently working with the biggest existing GIS 
company and they do not like the idea of using other ontologies that 
they cannot control. Another example is schema.org.

Again, Pascal's, Sven's and my arguments are not to redo everything from 
scratch but to have a precise and locally meaningful vocabulary and then 
link out instead of just having a collection of pointers to other 
namespaces.

Best,
Krzysztof



On 01/10/2014 05:43 AM, Raphaël Troncy wrote:
> Hello,
>
>>>> IMHO, you can just define whatever you want in your local
>>>> namespace, give it as much semantics as possible (or necessary)
>>>> and then have an additional layer of axioms that establishes
>>>> alignments. Many companies will (or do) it this way anyway
>>>> because they are afraid of giving up control. Will there be a >>
>>>> FOAF in 5 years from now?
>>
>> Indeed, I strongly second Jano's statement here. Agreement on one
>> (common) world view will never be reached - and is not really
>> desirable.
>
> Nobody has argued for this. Let's be specific and not making general
> statements. We are not talking about a company making a vocabulary but
> about a community group within W3C trying to get consensus on a
> vocabulary, and yes, the vocabularies hosted on http://www.w3.org/ns/
> are permanent[#].
>
> Furthermore, we are talking about the particular case where a
> class/property has been defined in a vocabulary A and that another
> vocabulary B is about to define a class/property with the *same*
> meaning, minor perhaps some usage note. We are not talking about a
> different case.
>
> So, I would like to understand why you believe it is better to indeed
> create this new class/property and add a
> equivalentClass/equivalentProperty axiom rather than re-using the
> existing class/property and potentially adding an additional usage note?
>
> I'm personally in favor of avoiding the creation of 200 different Person
> classes if those ALL want to define Person in the same way.
>
>> Maximizing re-use certainly is a valuable principle, but practice
>> shows us that many groups favor new developments instead of (often
>> more expensive) investigation for and adoption of existing bits and
>> pieces.
>
> This is what I call lazy ontology modeling. Do you have data that
> backups this statement that "practice shows that groups favor new
> developments"? My experience is the other way around, i.e. successful
> vocabularies re-use small vocabularies.
> Best regards.
>
>    Raphaël
>
> [#] Quoting Phil, "Indefinitely meaning some time between the point
> beyond which no one cares because technology has moved on and the heat
> death of the universe."
>


-- 
Krzysztof Janowicz

Geography Department, University of California, Santa Barbara
5806 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu
Webpage: http://geog.ucsb.edu/~jano/
Semantic Web Journal: http://www.semantic-web-journal.net

Received on Friday, 10 January 2014 17:09:31 UTC