Re: Property "geographic identifier" in LOCN

>> 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.

Just checked this: they seem to do both, e.g., there is a prov:Person class.


On 01/10/2014 06:12 PM, Krzysztof Janowicz wrote:
> 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:18:46 UTC