Re: Property "geographic identifier" in LOCN

Hi Raphael,

>> You have to define what do you mean by "import". And you should not
>> worry about those unintended logical consequences or please, provide me
>> with concrete examples of "unintended logical consequences" following
>> the re-use of terms from the top 10 LOD vocabularies (generally small,
>> with few axioms, but largely re-used) to back up this "fear".

The geo:lat/long is just one example (see the other email) and it has 
some very clear unintended consequence. There is of course also the 
whole sameAs nightmare but we should probably try to ignore this for 
now. I also already mentioned the case where buildings become persons 
due to the usage of FOAF for building names. You can also check 
Factforge for funny examples such as India being classified as a city to 
due problems with domains and ranges, and so forth.

>>> For instance, I would be very surprised if the US government would give
>>> up their own schema and use FAOF to annotate Persons.
>>
>> This is out of scope of this discussion.

To come back to the person example you made. If I am not mistaken Prov-O 
defined their own prov:Person instead of using FOAF and my feeling is 
that they did this for most (or all?) of their work. I am happy to check 
this, if required.

>> Let's be pragmatic ...

Yes, I absolutely agree but frankly speaking that was my starting point. 
What we are seeing right now is that the Linked Data cloud is falling 
apart. IMHO, one of the reasons is that we need to approach it a bit 
more scientifically. I guess we all known about the dynamics in the SW 
community that started the LD also as a reaction to over-engineering 
things but now we are running into the opposite problem, namely just 
hacking things together and this really makes me a bit nervous.

> Let's go back to the original problem of this
>> thread: geographical identifier.

I agree and please do not read my email as a criticism, attack, or 
whatever but as a discussion starter of what we really want to develop 
and how.

Best,
Krzysztof


On 01/10/2014 10:44 AM, Raphaël Troncy wrote:
> Hello Krzysztof,
>
>> maybe we can ask the question the other way around: Why would you prefer
>> to reuse single relation and class names from different sources?
>
> First, as I have already stated (I hope clearly) in other emails, I have
> no strong opinions for always choosing one way (re-use terms) or the
> other (create new terms, mint new URIs, and add axioms). I actually
> strongly believe that both are necessary depending on the use case and
> that there is (arguably) a large blurred zone that we are now
> discussing. This is because some have expressed opinions that we should
> nearly _always_ do one way that I'm reacting.
>
> Second, I'm all for fighting against this obesity of creating
> systematically new classes and properties when this is not necessary.
> Not all triple stores / knowledge bases are saturated with possible
> inferences based on provided axioms. If you don't provide axioms then
> you rely on ontology matching tools to find correspondences while this
> conceptual work might have already been made by the person who provided
> the vocab. Maintaining axioms can have costs, in particular when terms
> usage evolve. Etc. So yes, I'm in favor or re-using terms rather than
> redefining when clearly, one wants to express the same thing.
>
>> This will force you to import many vocabularies/ontologies which will
>> create unintended logical consequences.
>
> You have to define what do you mean by "import". And you should not
> worry about those unintended logical consequences or please, provide me
> with concrete examples of "unintended logical consequences" following
> the re-use of terms from the top 10 LOD vocabularies (generally small,
> with few axioms, but largely re-used) to back up this "fear".
>
>> Additionally, you really do not
>> know whether those relations and classes are really the same.
>
> Let's be pragmatic ... we are not talking about re-using terms from a
> vocabulary made by a PhD student on a table, but from widely used
> vocabularies, which have been published following good practices, with
> usage notes, for which the maintainer and the community are known and
> can provide vast amount of experience.
>
>> 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.
>
> No. This discussion starts with the simple problem of finding an
> adequate property for representing a geographic identifier and the
> problem of re-using an existing property or creating a new one. Full stop.
>
>> For instance, I would be very surprised if the US government would give
>> up their own schema and use FAOF to annotate Persons.
>
> This is out of scope of this discussion.
>
>> 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.
>
> Just to make sure I understand: the argument is taste ('Like') or
> keeping control, right? Do those guys plan to expose their vocabulary?
> Do they expect other people to re-use their vocabulary?
>
>> 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.
>
> Nobody is saying this. Let's go back to the original problem of this
> thread: geographical identifier.
> Best regards.
>
>    Raphaël
>


-- 
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 Saturday, 11 January 2014 02:13:41 UTC