- From: Matt Womer <mdw@w3.org>
- Date: Thu, 14 Jul 2011 11:06:22 -0400
- To: public-poiwg W3C <public-poiwg@w3.org>
Hi all,
Today's meeting minutes are available here:
http://www.w3.org/2011/07/14-poiwg-minutes.html
or as text below.
We had an excellent presentation from Sean Gilles of the Pleiades Project:
http://pleiades.stoa.org/
His slides are here:
http://atlantides.org/docs/slides/Pleiades-AAG2011/
We also determined that the next F2F meeting will be September 19-21 in Bolder Colorado, colocated with the OGC Technical Plenary meeting.
-Matt
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Points of Interest Working Group Teleconference
14 Jul 2011
See also: [2]IRC log
[2] http://www.w3.org/2011/07/14-poiwg-irc
Attendees
Present
Raj, robman, cperey, jens, seang
Regrets
Chair
Matt
Scribe
Matt
Contents
* [3]Topics
1. [4]Sean Gilles invited speaker
2. [5]Next F2F
* [6]Summary of Action Items
_________________________________________________________
<trackbot> Date: 14 July 2011
<seang> good morning
<cperey> hello!
<cperey> yeah! could you get me some as well?
<seang> slides:
[7]http://atlantides.org/docs/slides/Pleiades-AAG2011/
[7] http://atlantides.org/docs/slides/Pleiades-AAG2011/
-> [8]http://pleiades.stoa.org Pleiades
[8] http://pleiades.stoa.org/
<scribe> scribe: Matt
Sean Gilles invited speaker
seang: Raj thought the historical gazetter that I've been working on
would be of interest to you.
... I'm not sure what I'm working on are POIs in the same way, I
think the use cases around checkins, AR, are of interest to me and
that, for me, would be setting the bar for accessibility for ancient
world data.
Slide 1
seang: One of the goals of the session was to figure out the goals
of gazetters.
Slide 2
seang: This was to continue the work of the Classical Atlas Project.
This is a place to accumulate errata. The editors of the Berington
Atlas realized the publication cycle was so slow that it wasn't
feasible to put out new editions every year, so they needed a
digital form for the updates.
... It's an inventory of ancient place names and locations with
links to bibliography, etc.
... The goal is to make these resources widely available and
editable via the Web.
... Also to integrate with other projects.
Slide 3
seang: The project is run by a number of institutions (listed)
Slide 4
seang: There are a number of contributors (listed), I'm the only
paid staff.
Slide 5
seang: There are many users (listed).
s/Barington/Barrington/
-> [9]http://googleancientplaces.wordpress.com/ Google Ancient
Places
[9] http://googleancientplaces.wordpress.com/
Slide 6
seang: The origins of the data comes from tables of names (snapshot
on slide).
... This is what we have for structured data. Long lists of tables
like this.
... Note that the references are not meant to be exhaustive, but
starting points.
Slide 7
seang: We wanted the simplest thing that could work. So, a few
number of entity types.
... There's some overlap of the POIWGs entity types and ours. A
small number of entities seems to be a design goal of POIWG as well.
... These are probably obvious to engineering types, but I wanted to
be explicit for AAG.
Slide 8
seang: This is the simplest possible view of our model. Names,
locations and temporal annotations.
... A place is a context or container for names and locations, and
those places can then relate to other places.
... We have some unconventional places: unnamed places, unlocated
places, fuzzy places and locations that are determinable but not
needed (e.g. rivers in ancient Europe known in texts, but that
aren't to be treated with any kind of accuracy).
... Attributes of places include: metadata Dublin Core, references
(scholarly works)...
Slide 11
seang: In our work we needed to be more focused on names. Our users
are primarily researchers of texts.
... Our names have richer attributes than often find in GIS.
... We record the language and writing system, their attested form,
transliteration, accuracy of transcription, completeness of
transcription, our certainty of association with a place and
evidence.
Slide 12
@@
Slide 13
seang: This is a transcription of a ??
@@evidence@@
Slide 14
seang: There's a highlight on the 7th line of "coris" that is a
locational term.
Slide 15
seang: How to integrate with Web architecture
... Everything has a URI
... The fine grained API for this is the Web and HTTP
Slide 16
seang: Early on we focused on features, thinking in a standards
oriented way of how we wanted our entities in the model. Features
have now been relegated in importance to names and places.
... @@ aggregation @@
... When putting it on the Web we wanted precise coordinates and
were based on other digitization projects. We realized we could go
ahead and publish these resources, mint URIs for these things, even
without precise coordinates yet.
... The needs for our users were on the names, not the exact
locations.
... The Web is ideal for these kind of things, but interaction is
kind of chatty and it's hard to get slices of stuff by interacting
with Web resources. So we realized we had to give other
representations like tabular dumps.
... Lots of users want to write rich entries for things -- bit of
scope creep.
... The entries are becoming rather encyclopedic.
... Our use of the term place is different than other people's
understanding.
... POIWG could nail down a particular concept of place.
... Then projects like ours could say we're more or less like the
POIWG place.
raj: Can you clarify the features concept there?
... Features are spatially focused.
... Is that what you meant?
seang: When I said it's a map concept it's things represented on a
map. Geographic features, cultural features, etc. In the talk
someone pointed out the OGC abstract feature model as well, in that
model largely any physical entities are features.
... But in a gazetteer, we're more concerned with names and change
in names over time.
raj: A physical object vs a conceptual object?
seang: Yes, that's fair to say, though I came to realize during
those sessions that there are different gazetteers, some more
concerned with concepts, other with features.
Slide 17
seang: The nature of our places gives us some properties of a
historical gazetteer. A single Pleiades place can have multiple
names and times.
... It provides an entry point for viewing these things on a
timeline and seeing transitions.
... But at the same time some people want to do encyclopedic work
with them, others want to create networks of relationships.
robman: Is a new place created when a new name appears?
seang: Yes, in our model.
... If someone were to come up with a new name and marshall enough
evidence that this was a real place name and not a personal name,
then we would model it as a name within the context of a place, even
if it's unlocated or unknown other than through it's name.
robman: Would a place persist across a name change?
seang: Yes, as we model it.
... I'm sure this group has been through a lot of these use cases.
?? was talking about the changing nature of name over time.
... Places change over time from being say, a pub to an intersection
to a major cultural landmark.
... Modeling that kind of thing wasn't part of the initial design
and I'm not certain yet how well we can cover that.
... We can handle changes in names over time, but change in nature
of place over time we don't handle explicitly. We have a concept of
a categorization for places, but it isn't temporally scoped.
Slide 18
raj: Can you talk about URIs? The WG has a real interest in getting
IDs right.
seang: Wiki seems to say that all entities will be identified with
URIs. This isn't a revolutionary concept in the geo world anymore.
... It's become not only commonplace but best practice.
... Our data is stored in a big tree. There's a line where I have a
URI for a place.
<seang> uri for a place: [10]http://pleiades.stoa.org/places/89152
[10] http://pleiades.stoa.org/places/89152
<seang> uri for a name:
[11]http://pleiades.stoa.org/places/89152/coria
[11] http://pleiades.stoa.org/places/89152/coria
seang: If I understand right, your names are an attribute, not a
separate entity.
... What's interesting in Pleiades is that they can parse extra
information out of the URI based on these paths. Bound to have some
trouble if we have a segment attached to a places URI to get a name.
... You can see our model leaking through to the URLs.
... It gives them a little too much information maybe.
raj: Interesting to have name have another URI.
seang: Place is tricky. We can agree on names and locations. Those
are first class resources and the name is there to collect the place
and locations together. Place is a concept for scholarly research
and therefore a place to collect links on the scholarly work about
the place.
raj: A POI is combination of name, place, person doing the place and
the boundary.
... The name and the demarcation of the place is really effected by
who does the naming.
... We've struggled with the concept of the place changing based on
who is doing it when.
matt: There's always one place associated with a name?
seang: Yes. In our data base of 35k, there are a lot of names that
are reused over time.
... Common example is a Roman place name you see on maps, 'ad
fines', which means "at the border".
... We have forty different occurrences of this name that are
thought to be distinct places. We don't have that mapped to those
distinct places, but that string reoccurs within 40 different
places.
... There will be different time spans for them, different evidence,
so it didn't make sense to have one.
... Same for names of Emperors or Deities.
... Appelonia is scattered all over the Mediterranean. They are
different places, we treat them as different instances and not the
same Appelonia.
matt: What's your process? There's a kml file and the site, how do
you go between them? From the KML expand into the site?
seang: We scrap the Barrington atlas. We accept edits in KML, but we
don't have a slick way of handling that -- there's a lot of power in
KML, but it makes it a pain to parse. The big KML dump that we have
is not yet 100% fidelity recording of what we have in our database.
... I'm intrigued by the idea of serving KML up for a single place,
and have that be editable and have it posted back in order to make
updates.
... Mass market tools like Google Earth have functionality for
changing the location of a placemark, but not a lot of place to put
structured information about placemarks, so they can't use that for
changing the temporal attestations or the references and such.
... KML for us is at this time is a representation of our data just
meant for discovery and visualization and not much meant for looking
at the history of a place.
raj: The purpose of this group is to create a foundation for POIs
that everyone could use. What would you be looking for from this
group to make itself valuable to you to make you publish in this
format?
seang: A lot of the scholars that I work with are pretty buried in
their texts. To be of interest to Pleiades, for museum visitors,
etc, if the work takes off, people would be interacting with these
things as POIs. If Pleiades were representing itself in the same way
it could provide access points to the historical and scholarly work.
... I'm curious how it will come about. I don't use many of the
checkin services, but people are checking in at historical sites.
I'm interested to see where Pleiades fits in. I don't think you can
check into historical places, but who knows.
... I know of a professor who assigned students to use Gowalla to do
historical re-enactments. Creating logins, checking into historical
places, write up experiences, etc, based on history.
robman: The URI gets you a place, but is there a query side?
seang: We do have a query interface, but it's not say GeoSPARQL.
... We have a number of things backed by search results, so we have
URIs representing common query sets.
... People can build these too.
... Can create permalinks for queries.
robman: Metadata tagged queries? Or geo queries?
seang: Both.
... I'm avoiding a lot of API work because at the moment we don't
have so much data that a user can download the whole thing.
... We don't have the same needs as a POI database that might have
millions or tens of millions of entries.
raj: There is a public mailing list, we'll keep discussion up there.
matt: Where is the metadata?
seang: The title and descriptions are dc meta data.
Next F2F
<robman> thanks seang that was intereting
matt: code for working session: 764323
<robman> bye
matt: Raj has offered us space at the OGC Technical Plenary from
19-21 September. Mark your calendars, our next f2f will be there.
Summary of Action Items
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [12]scribe.perl version 1.136
([13]CVS log)
$Date: 2011/07/14 15:02:47 $
_________________________________________________________
[12] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[13] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43
Check for newer version at [14]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
FAILED: s/Barington/Barrington/
Succeeded: s/ over time//
Found Scribe: Matt
Inferring ScribeNick: matt
Default Present: Raj, robman, cperey, jens, seang
Present: Raj robman cperey jens seang
Found Date: 14 Jul 2011
Guessing minutes URL: [15]http://www.w3.org/2011/07/14-poiwg-minutes.ht
ml
People with action items:
[15] http://www.w3.org/2011/07/14-poiwg-minutes.html
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
End of [16]scribe.perl diagnostic output]
[16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 14 July 2011 15:06:28 UTC