- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Tue, 27 Oct 2015 18:56:41 -0700
- To: Ed Parsons <eparsons@google.com>, public-sdw-wg@w3.org
- Message-ID: <56302B59.7060306@ucsb.edu>
Thanks Ed. This is a paper that I really like:
http://iswc2014.semanticweb.org/raw.githubusercontent.com/lidingpku/iswc2014/master/paper/87960097-scientific-lenses-to-support-multiple-views-over-linked-chemistry-data.pdf
. See, for instance, page 11. Their approach provides the flexibility
many of us need without giving up on the formal characteristics.
Best,
Krzysztof
On 10/27/2015 06:22 PM, Ed Parsons wrote:
> Thanks Krzysztof, for your comments.. I will leave it to the editors
> to make any response, but duly noted thank you !
>
> ed
>
>
> On Tue, 27 Oct 2015 at 23:04 Krzysztof Janowicz <janowicz@ucsb.edu
> <mailto:janowicz@ucsb.edu>> wrote:
>
> Hi,
>
>
>>
>> Hope things are going well in Sapporo and sorry not to be able to
>> join you.
>
> Same here. I was also trying to follow the IRC protocol and would
> like to comment on the owl:sameAs issue. I agree with ahaller2's
> statement that we should not ignore what is and has been best
> practice for Linked Data over the years. There are clearly some
> issues with the broad and often misleading use of owl:sameAs but
> it is still the only relation we have that has a formal semantics.
> It also states that two URIs point to the same thing which is a
> very useful and powerful statement as it establishes identity.
> There is a lot of new work that proposes a nested solution by
> introducing weaker statements as well. Typically, these solutions
> combine owl:sameAs with SKOS (e.g., skos:closeMatch) and
> rdfs:seeAlso. Predicates such as samePlaceAs have been proposed in
> the literature but their semantics remained unclear and this is
> why we do not see them in the wild.
>
> Best,
> Krzysztof
>
>
>
> On 10/27/2015 02:12 AM, Bill Roberts wrote:
>> Thanks Ed. Will check through today's notes too and contribute if
>> I can. Time zones and other travel at my end have made it hard to
>> be more closely involved
>>
>>
>>
>>
>>
>> On 27 Oct 2015, at 09:07, Ed Parsons <eparsons@google.com
>> <mailto:eparsons@google.com>> wrote:
>>
>>> Hi Bill,
>>>
>>> In answer to your questions we ( the people in the room) came up
>>> with...
>>>
>>> If we take the simple approach, does it lead to contradictions
>>> or data consumption problems?
>>> *That's life we accept it :-)*
>>>
>>> Can we let people add spatial data to the web in the way that
>>> suits their purpose and still make it useful and interoperable?
>>> *Yes to be tested however against the BP work*
>>>
>>> Where do we strike the balance between ease of publishing and
>>> understanding vs strict standardisation/consistency for easier
>>> machine readability?
>>> *Not sure what you mean, but this might be application specific
>>> - we need to gather examples of different approaches.*
>>>
>>> Thanks so much for taking a look at the minutes.
>>>
>>> Ed
>>>
>>>
>>>
>>> On Mon, 26 Oct 2015 at 11:52 Bill Roberts <bill@swirrl.com
>>> <mailto:bill@swirrl.com>> wrote:
>>>
>>> Hi all
>>>
>>> Hope things are going well in Sapporo and sorry not to be
>>> able to join you. I’ve been reading through the notes from
>>> Monday’s discussion and just thought I’d contribute the
>>> following, that I was writing up over the weekend. If
>>> you’ve already covered this topic at the meeting, feel free
>>> to park this for now - I realise there are many other things
>>> to cover too.
>>>
>>> Things, Features, Spatial Objects
>>>
>>> I think we should try to accommodate a simple
>>> straightforward data model wherever possible. That doesn't
>>> preclude a richer or more precise data model when
>>> circumstances require, but in many cases I think we can
>>> often just work with descriptions of a Thing (without having
>>> to puzzle about whether it's a thing or a feature or a
>>> spatial object). There might be lots of different
>>> descriptions of that Thing from different sources in
>>> different contexts but that is already a well established
>>> practice on the web and in the world in general.
>>>
>>> I might want to set up lighthousecatalogue.com
>>> <http://lighthousecatalogue.com> where I say:
>>> Beachy Head lighthouse is in England;
>>> has latitude 50.7337;
>>> has longitude 0.2414 .
>>>
>>>
>>> Jeremy's rival lighthousespottersguide.com
>>> <http://lighthousespottersguide.com> ("For the lighthouse
>>> connoisseur") says
>>>
>>> Beachy Head lighthouse has geometry X .
>>> X asWKT "MULTIPOLYGON(blah)" .
>>> X asGML "<gml> blah </gml>" .
>>> Beachy Head lighthouse has a height of 43m;
>>> is red and white ;
>>> produces two white flashes every 20 seconds;
>>> has web page
>>> <https://en.wikipedia.org/wiki/Beachy_Head_Lighthouse> .
>>>
>>> These are clearly two different representations but we don't
>>> necessarily need a spatial object or Feature to manage this
>>> situation.
>>>
>>> Jeremy and I might use the same URI for Beachy Head
>>> lighthouse or different ones. If we use different ones, one
>>> or other of us, or a third party, might want to assert that
>>> those URIs have a sameAs relationship and then the faithful
>>> users of my Lighthouse Catalogue can also easily find out
>>> that it's red and white.
>>>
>>> In some cases, you might want to apply provenance or
>>> versioning information to those descriptions - and there are
>>> various ways to do that, whether by using the linked data
>>> 303 approach to separate real world thing and a document
>>> about it, or just having some document that has an
>>> identifier. Maybe we should recommend how to do that for
>>> spatial data.
>>>
>>> Jeremy's side project,
>>> historyoflighthousesurveyingtechniques.com
>>> <http://historyoflighthousesurveyingtechniques.com>, might
>>> need to go further and introduce specific identifiers for
>>> different representations of the lighthouse over time. So
>>> that involves choosing a modelling approach appropriate to
>>> the data to be represented. But my simple list of where to
>>> find lighthouses shouldn't have to worry about that.
>>>
>>> I’m not sure of the answers to these questions:
>>>
>>> If we take the simple approach, does it lead to
>>> contradictions or data consumption problems?
>>>
>>> Can we let people add spatial data to the web in the way
>>> that suits their purpose and still make it useful and
>>> interoperable?
>>>
>>> Where do we strike the balance between ease of publishing
>>> and understanding vs strict standardisation/consistency for
>>> easier machine readability?
>>>
>>>
>>>
>>> --
>>>
>>> *Ed Parsons*
>>> Geospatial Technologist, Google
>>>
>>> Google Voice +44 (0)20 7881 4501
>>> www.edparsons.com <http://www.edparsons.com> @edparsons
>>>
>
>
> --
> Krzysztof Janowicz
>
> Geography Department, University of California, Santa Barbara
> 4830 Ellison Hall, Santa Barbara, CA 93106-4060
>
> Email:jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>
> Webpage:http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/>
> Semantic Web Journal:http://www.semantic-web-journal.net
>
> --
>
> *Ed Parsons*
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501
> www.edparsons.com <http://www.edparsons.com> @edparsons
>
--
Krzysztof Janowicz
Geography Department, University of California, Santa Barbara
4830 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 Wednesday, 28 October 2015 01:57:13 UTC