Discussions on Transportation
Start a New Discussion
-
-
Type Transit Stop has a property for "service hours", but service hours may be different for different transit lines at the same stop. Take Balboa Park, for example. It's serviced by several BART lines and the Muni J line, each with a different time for last service of the night and depending on what day of the week it is.
The combined CVT would be ugly, but perhaps for accuracy the properties "transit lines" and "service hours" should be merged together?
-
Heinously ugly. Plus a nasty refactoring -- we'd have to stop using the Open Times type, and put each of its properties on the combined CVT. Hmm. Plus we couldn't actually migrate the data for any stop with more than one line, since we wouldn't know which lines had the same start/end times.
-
I know, but what does "service hours" really mean otherwise? It's meaningless.
-
I agree that it's meaningless, and would be tempted to remove the property. If we're going to have service hours at all, it should be on transit lines.
-
I second the removal of service hours from transit stop without a (nasty) refactoring. Transit line already has a property for service hours.
-
Bump. Are we going to do this?
-
This is meaningful in places like New York where some stations are locked up after hours.
-
Hmm. My assumption for this proposal is that the service hours of a station is equal to the combined service hours of trains that serve that station.
If Station Foo is closed at 2am, and serves lines 3, and 4, the new properties for line-based service hours will be able to model the following:
Line 3 at Station Foo ends service at 12:23am
Line 4 at Station Foo ends service at 1:45amReilly, the question is, do we need to capture the fact that Station Foo is "open" between 1:45 and 2am even though there's no service there?
-
Another thing to think about: Hours for anything -- train stations, restuarants, museums, etc. all get stale over time. Given that data like this is inconsistently updated, I think a necessary piece of metadata is to mark when the open times were last reviewed so that somebody using the data can judge how much to trust it.
-
@robert: the data is already timestamped -- are you suggesting a new property, or that the timestamp be more easily accessed by users?
-
I've entered/typed many transit stops and I just ignored service hours due to Faye's point about transit stops being serviced by several transit lines. It's meaningless, for example, for huge transit stops such 30th Street Station in Philadelphia or Gare du Nord in Paris to have listed service hours as those stops are served by long-distance trains as well as local and light-rail transit lines that have varying hours. If the intention is for service hours to refer to the closing and opening of station doors, that's not entirely clear when one examines the schema. The property description of "Open Times' captures the hours and days of business operation for a retail location" seems too confusing when it comes to a transit stop.
Besides, many transit stops that are street locations don't really "open" or "close"; there are only meaningful first and last service times by particular transit lines servicing particular locations on particular days.
-
@ Jeff - I think there needs to be a timestamp that says when the dates were last affirmed to be correct and that that value is visible. Given that it is an editorial annotation, I think it has to be an editable field.
-
I guess the idea of the visible timestamp is some sort of way of letting people know the "data might not be accurate - so don't go planning your trips based on this"?
It still wouldn't help with emergency closures or last minute changes of time. You'd still need a disclaimer; and I see this is already provided by section #18 of the TOS.
The timestamp would just add clutter and complexity.
-
No, the timestamp is says when the data was last edited, but when it was last confirmed to be correct. If it was in the recent past, then it's safer. If a long time ago, then much less so.
It also signals to the community when it might make sense to confirm and possibly correct the data.
For example, if the data was bulk loaded 2 years before (when the timestamp was set), it's unlikely to be accurate unless somebody looked at it. If somebody did look at it the month before, it has a much higher chance of being usable.
Without the timestamp, there is little confidence at all when the data can be used. In that case, I wonder if it even makes sense to load it as it will mostly be ignored in practice.
-
Ah, I see - if data was uploaded 2 years ago and then checked again yesterday and found accurate the timestamp will still show 2 years ago. Yesterday's check will be unknown to us as accurate data does not require any changes - and only changes leave new timestamps.
This is common to all data which may change in time, not just transport timetables. e.g. a check to see if someone is still alive or if Pluto is recategorised, or a reinterpretation of historical events based on new research.
It's part of a bigger discussion of confidence in data, related closely to that of verification of data from verifiable sources.
-
Back to the original point: Bryan's ready to wipe service hours off the face of the graph. We have one vote for clemency from Ryleh, and votes for nuking from Faye, Skud, and krsalis. Anyone else care to weigh in before Bryan pulls the trigger? (How many mixed metaphors can I manage in one message?)
-
Some stations are open for ticket purchases even though trains may not be stopping there. But could these be co-typed as business locations, which does have an opening hours property?
If so, nuke the property from Transit Stop.
-
-
-
What are the chances of (specifically for train lines, tram lines), an 'adjoining' stop?
I would have said next/previous, but that's kind of subjective.-
The model is simple enough; the nomenclature is tricky though, since we'd need two properties (one for each way). Next/Previous might be better than Adjacent Stop 1/Adjacent Stop 2, assuming it was well-documented, but it's not really very satisfactory.
-
I actually was thinking 'adjacent stop' could have multiple entries.
IE:
Case 1:A central station, which is the terminus of many lines
Adelaide central station
* Mile end station (the next stop on the Belair line)* Outer harbour station (the next stop on the Outer Harbour line)
Case 2:
Goodwood station though is midway along a line.Goodwood station
* Mile end station (before)
* Belair station (after)
-
Sounds like it would probably have to be a compound-value type, containing the Transit Line and the adjacent Stop, then.
-
Next/previous is a problem, because how do you tell which direction you're travelling in? Montgomery BART is the next station from Powell if you're heading towards the East Bay, but it's the previous station if you're heading toward SFO. (Sorry doconnor for the SF example, but I'm sure you can imagine an Adelaide equivalent.)
I think "adjacent" is probably better than next/previous for this reason.
-
There are also problems with express trains. During rush hour a number of trains operate as express trains, and only stop at one or two major stations.
As an example during typical hours the next stop from Victoria (London) would be Battersea, but for some trains the next stop would be the next major station, Clapham Junction.
-
The CVT would address sprocket's concerns, since express trains/buses are treated as separate lines. The display of such a CVT would be kind of weird to look at, though, except for stops that only serve a single line, since (for non-terminal stops) there would be two values per transit line, which would get cluttered very quickly. (This is only a display issue, and probably shouldn't guide the model too much, but I thought it was worth mentioning.)
-
Bump. Are we going to do this?
-
+1 from me :D
-
I'll slap together a model on sandbox, so people can see what it looks like.
-
OK, it's up.
Here's Adelaide Railway Station, a terminus for several lines. (Note that three lines share one of the adjacent stations.*)
Here's a midpoint station that is on three lines, each of which have the same two adjacent stops.
And here's a midpoint station on three lines, which share one adjacent stop but which start to diverge in the other direction.
*I've modeled this by making the "transit line" property non-unique. It could also be done by making the property unique, and therefore always requiring separate entries for each line.
-
-
-
Annual Average Daily Traffic...
Wikipedia has plenty of data about this in the infoboxes for Bridges...This would be useful for all sorts of transportation types (roads, tunnels, transit systems, airports, etc.)
-
+1 Nice idea for a property with plenty of data.
but how to implement it..... a new property on each of the existing types, or a new type (called "transportation node" or similar) which the existing types all include?
-
I kinda like the node idea, we could add Toll costs (dated property for history of increases?).
-
Thinking more about the "transport node", we could have some sort of connectedness to it, in order to model transport networks: say, a "connected to" property expecting other "transport node".
It would abstract some of this away from trains/roads etc.. I'm not sure this is totally desirable, but it would be great for modelling multi-mode transport networks.
-
The wikipedia infobox for bridges has only 305 (out of ~1800) infoboxes with any data in the "traffic" attribute, and it seems pretty noisy. I'm not sure automatic extraction will yield that much.
Roads have properties for linking them to other roads. One advantage of making these linkages type-specific is that the property names are more self-explanatory.
There is always a trade-off in abstraction -- machine vs. human readability. In this case, a more abstract schema would make a machine implementation somewhat easier (less conditional code looking across a handful of types) at the expense of data fields that are immediately understandable.
-
-
-
hi, howbout a reciprocal property with Bridge disaster?
-
-
-
Hello,
i think it would be great if you could add a google maps links to a specific loctaion, which will grab its map accordingly.
currently, if I got it right, the Location type have this option, when you write something under Contained by. but in my case (Israeli street names), the map is of the town only. although i have seen other road (in the US) which have a better map view.
few weeks ago, Google added Israeli streets too (with both hebrew and english spellings), so maybe there needs to be some twiking to get it to work).
for example Borokhov street in freebase and its location in google maps (note the different spelling though).
Thanks,
Doron.-
Doron,
The mapper will map the streets if the road ends are present and have their geolocations filled out. Unfortunately, the geobot (which will automatically add geolocations to locations with addresses) doesn’t currently handle intersections, but if you have the geolocations, you can fill them out now. We are working on improving geobot’s capabilities, but that’s the way to do it until then.
-
We have a geobot which runs through Freebase's locations regularly and converts street addresses (eg. 123 Smith Street, Sometown) to geolocations (lat and long). I believe -- though I'm not 100% sure -- that it uses the Google API to do this, so if Google Maps can find your address, then the geolocation will be set on the topic, and thus you'll get a perfectly pinpointed map on the topic page.
-
-
-
sometimes the streed is named after someone or something, but since the offical street name is different then the offical person or something name (could be a nick, or different spelling), you can't or you don't want to make that person/something also a road.
i have this problem with an israeli street name i created. in here, the offical english spelling is different then what most ppl use, so i cant make the person be also a road, or vice versa.
the road:
http://www.freebase.com/view/guid/9202a8c04000641f8000000009172699
the person:
-
-
-
-
-
Hi!
Isn't it a bit weird to find roads under the Transportation type? I would put roads under "Infrastructure", or something. In the Transportation type I would put "Train", "Bus", "Plane", etc, i.e. MEANS of transportation. But I can see where the grouping came from. But "Bridges"?
Well, I assume what we really need is a way to tag types, i.e. "Roads" could be tagged with the words "Connection", "Infrastructure", "Car", etc. I'm not sure, but aren't hierarchies pretty dated for grouping stuff?
Anyway, I would appreciate a type for Travel, i.e. if someone could spec up what "Travel" is (or perhaps "Trip" fits better). It would be something along the lines of:
1. Involves one or more persons (it wouldn't be travel if it was a letter, for example)
2. A Travel would consist of one or several Legs.
3. Each Leg is between 2 Locations, a start location and an end location.
4. A Trip Leg involves the moving of the persons listed under 1 between the start and end points of the Leg.
5. In each location, the persons can stay, perhaps in a Hotel
6. Rent car at the location
7. The transportation between the start and end of a Leg is with one (or several?) means of transportation (i.e. Bus, Car, Train, etc)
See, this is a can of worms, unless you know the domain, or at least know the lingo of the domain.
I'm surprised this hasn't been done yet in freebase, since booking travel is one of the poster childs of the semantic web, right?
Best regards,
Mats Henricson-
Mats -
We actually thought that roads (and bridges) should go under something called "infrastructure", and indeed that could happen. At the time, we were at a loss as to what other types would go in there (given the Architecture domain).
Domains are not intended to ontologically significant. They are intended to define a community of administrators who understand the breadth of the domain well enough to competently control the types within it. Domains are not hierarchical, although our 'all types' page does have categorizations that suggest that there is some deeper nesting, but this is just a visual crutch until that presentation is crushed under its own weight as the number of domains increases.
As for your 'travel' type example, I think the name 'trip' is right. A type should define a very concrete collection of topics that have properties (fields) in common. A trip has properties -- a starting location, ending location, intermediate locations, etc.
My point is that what's in domains need not be so charged -- there will undoubtedly be disagreements, but the stakes are much lower than people realize (and what's suggested by our type page). I believe that in the very near future, most types will be found not through that type page, but more organically through search and 'lateral' discovery through the links on topic pages.
I encourage you to model the trip type in your private domain. After you've done so, this type could be one of the first types in a 'travel' domain, which might also include hotels, etc. -
A Route is part of the Transport Domain.
A Road inherits from a Route.
Notable individual structures, e.g. bridges, that compose the Route are part of the Architecture Domain.
I see 'trip' as the process of undertaking a journey, and so belongs in the Travel domain.
For example a road that is never used (for any reason - unfinished, baricaded off, isolated etc.) will never be part of a 'trip', as nothing will ever travel upon it, yet it is still Infrastructure and part of a Transport network, albeit a white elephant of a network.
As a further example, say there is a flight route between London and New York. The actual flight path does not have any infrastructure (it is through the sky), it is just an abstract connection of two distant points, and so is not part of the Architecture Domain (although the Airport buildings at either end may be).
The flight path (Route) is part of the Transportation Domain. However the act of taking the 11:32 am LHR-JFK flight would be the Travel Domain.
The only criteria for a Route in the Transportation domain is that the connected points have physical locations, e.g. a town or city. (to differentiate it from a Graph - see Graph Theory)
-
-
-
I am starting to develop Rail Lines and feel there is a huge overlap with Roads.
I think it best if the common features are placed in a generic type, and Road and Rail Lines inherit from it (and tram lines, air routes, sea lanes etc. etc. ). I suggest the generic type be named Route.
I suggest that Road and Rail Line inherit from Route.
Road Junction, Rail Junction inherit from Route Node.
Road End also inherits from Route Node.
Highway System and Rail Network inherit from Route Network.
Any comments?
-
-
-
-
Hi, I'm new here, so please bear with me.
I'm confused about Transportion being under "Time and Space" and Aviation under "Travel and Dining".
I'm looking for a place to put Automobile and it's not clear to me. Maybe there should be a type of "Vehicle" somewhere under which Boat, Automobile, Bicycle, Aircraft could live.
Again, I'm brand new, so please set me straight, if necessary.
Thanks,
-Jon-
Welcome Jon!
I can see how the categories might be a little confusing. I'm sure there will be some shifting around as more data types are developed, and we may well end up with something along the lines of what you propose.
In the meantime, if you want to work on an automobile type, you should develop it in your private domain first. Once it's fleshed out and you have some instances associated with it, drop a note in one of the discussion threads to alert the domain administrators so they can take a look at it. You might want to work on sandbox.freebase.com as you're getting going, as explained here:
http://www.freebase.com/view/helptopic?id=%239202a8c04000641f8000000004531a91
The sandbox is a good place for experimentation. If you just signed up today, your sandbox account should be working by the end of the day on Monday.
I hope that helps! -
P.S. I just noticed that another Freebase user (ken) is working on an automobile type as well. You might want to take a look at what he's done and post something on that type's discussion thread if you have thoughts or suggestions.
-
-
-
But, I haven't understood how properties works. I'm a Java programmer, so I have a pre-configured notion of what a property is, and was a bit lost when I noticed that there didn't seem to be a way to specify a List. For example, to me, a Trip would consist of a list of Legs. A leg would consist of a start location and an end location. Is there a way to hack such types by hand, in a plain vanilla editor?
Mats-
A property can contain an arbitrary number of items and the items can be ordered. For instance the "tracks" property on a Musical Release has the order that the tracks appear on the album.
For a trip, you could have a property called "locations visited" that expects type "location". You add all of the locations and set the ordering.
See my mockup of this:
http://www.freebase.com/view?id=%239202a8c04000641f80000000042b7f19#NO_GO -
To clarify a little more -- properties are very versatile. Unless a property is marked 'restrict to one value' in the type editor page, it can be a collection. In fact, very few properties have the restriction, so collections like this are very common.
Also -- to order a property list, you need to select "view all" from the menu for the property (found to the right of the property name". Then select "reorder list". You can then move the items to the correct ordering and save your changes.
-
