Discussions on jeff
Start a New Discussion
-
-
-
Currently, Employment Tenure is defined by two dates that connote the start and end of the tenure. I would like to be able to add supporting data to what is an unknown tenure that would assist future contributors. I suggest that we add a field called KnownToBeInPositionDuring. In this manner I could add a year that I believe someone held a position, but was not necessarily the first, or last, year of their employment. Alternatively we could always resort to the handy-dandy multi-purpose field name that is suitable for just about every occasion: Notes.
-
i like this idea. we could just hide the property. (cc-ing jeff) do you have much data?
-
...could also just name it During.
@ this point I am just getting my feet wet with FB (what's the preferred acronym that avoids confusion with Facebook?); Yesterday I attended the New York Freebase Workshop http://wiki.freebase.com/wiki/Freebase_Workshop_NYC_2009 where I met: Robert Cook, Jamie Taylor, and Will Moffat
Alas, I am currently doing my edits by hand and I am not a possessor of a large data-set with Freebase Potential...@ least not anything obvious, yet.
Here's a new question: Where can I suggest, or edit, the Help Text that displayed when you click on the (?) button...here's a link to a screengrab: http://aviary.com/artists/dme212/creations/freebase_helptext
--Dan
-
welcome to freebase dan~ the pink stuff comes from the schema documentation, which in the case of /people/person is locked with admin permissions so its only possible to improve documentation for types that you've created yourself... frustrating i know, because schema builders don't always properly document things. @workshop - lucky! those guys never seem to travel up to northern Ontario....
-
But the admins are always open to suggestions for improvements! The best place to make the suggestion is on the discussion board for the type in question.
On the larger question of known good dates, I'm pretty sure this has come up before. Let me see if I can find the old discussions, in case they shed any light on the issue.
-
Well, here it is -- not so enlightening after all. The main issue, schema-wise, is that the same problem potentially exists for all types with a date range, and is related to the perennial "circa" problem with single dates.
-
Spencer: I thought you were in Toronto? If so, I am in fact planning to be there in February and was going to talk to you about having a Freebase meetup while I'm there. It would probably be during the week starting Feb 8th.
-
I'd really rather not end up with two properties to determine who worked where when: that's just going to make the life of anybody searching for data that much harder. I know it's not perfect, but how about just setting "start end" and "end date" to the year in question?
-
-
-
Hi, the Law commons is regrettably lacking. There are multiple Law and Legal user bases in existence, such as:
http://www.freebase.com/view/user/skud/legal http://www.freebase.com/view/user/tsegaran/legal
May I request a schema review for the purpose of promoting some of these types to Commons? We can use types such as Judge and Legal case and Court Ruling.
-
-
-
Gentlemen,
You are currently in the Hall of Shame.
-
-
-
Given only the existing properties of Retail Location (name, address, hours of operation), there's no way to know what that retail location sells or what industry it is a part of. What is the best way to include an industrial classification with a topic that falls under the Retail Location type?
Could another property be added to the Retail Location type mirroring the way that the Company and Industry types are bi-directionally linked by the "Companies in this Industry" property of the Industry type? Or, using the existing types, should a Retail Location also be typed as a Company in order to be classifiable in an Industry? (The second option seems like overkill, especially for small businesses that are poor matches for the definition of the Company type.)
I would like to do a bulk upload of Retail Location data for London, England, but first want to be sure I have the proper structure for my data.-
Just came across this. I'd definitely support a business category property on business location.
It would be useful to model whether a business location operated by a company is a cafe or their offices.
-
How about "type of business location" as a name?
-
That would work, although I'd try to avoid using the word 'type' in schema - it gets confusing when discussing schema types.
-
-
-
I'm currently looking at restaurants. Many of them are owned by parent groups or chains, and will have opening and closing dates. Can we add a closing date to business location?
Defunct company is the only other related topic, and it imports all of company, which is a bit of overkill.
-
I agree, we need a closing date for business location.
However, I think business location might be better off including 'dated location' type?
-
I'd support adding a closing date. Since we don't treat Business Locations as Locations, I don't think using Dated Location is the right approach.
-
If I understand https://bugs.freebase.com/browse/DA-808 then business location will be IS-A location. If so, can we reconsider using the dated location type? This would allow us to then delegate business location's opening_date property (and a new closing_date property) to the relevant dated location property.
-
ah no! it's to remain HAS-A location http://markmail.org/message/db76hw73tdof6upm?q=freebase+list:com.freebase.data-modeling+date:200911+from:%22Jeff+Prucher%22&page=1
Scrap the request for dated location!
Could we get a /business/business_location/closing_date though?
-
Yes! We should have done that ages ago -- sorry about that!
-
-
-
if we are using 'magazine genre's instead of subjects, magazine genre should then attatch to subject.
-
either way, we should clear this up. is magazine genre the same as subject? it is being used as both 'magazine type' (eg men's magazine) and 'magazine subject' (eg hockey) ambiguously.
-
... if it's a subject property, and its not using our general subject type, it needs a phylogeny.
-
Looks like this type is just badly defined. It really should just be for the genre (and, fortunately, mostly has been used that way) and not the subject. (The two are perhaps more intimately connected for this type than genre and subject usually are, but that's no excuse for bad documentation.)
-
i like genre better too subjects can go into /book/periodical/subject i'll do some work cleaning this up
-
-
-
i suggested this before this type got promoted, but it got fanned over somewhere,
we definetly definetly should merge this type with this one, which already has tons of data, and it seems has been overlooked.
-
I agree somewhat. Funny, I just posted my Need to expand beyond just followers. And THEN, I read your post here. LOL. However your suggestion is fairly comprehensive. I was thinking more along the lines of what I suggested, since not all followers necessarily are orthodox (strict followers), so a quick selection drop down might be a better approach and cover a broader use? I thinking on just the basics as shown in this table ... http://asiarecipe.com/religion.html
X - prohibited or strongly discouraged A - avoided by the most devout R - some restrictions regarding types of foods or when foods are eaten O - permitted, but may be avoided at some observances
Anyone else ? Let's get this merged somehow. I need it somewhat and I'm sure others do as well. Put it to a vote.
-
-
-
-
Why is the Employer type included by default, can I ask for the reasoning behind that?
I feel that most organisations that aren't businesses aren't employers (cub packs, programming meets etc.)
-
Remember that Freebase included types aren’t a strict subtyping mechanism; you can always remove a type from an instance. So a programming meet could be typed as an Organization, and then Employer can be removed.
It was felt (by whoever did this—I’m not sure who) that *most* organizations likely to be in Freebase are also employers. If you disagree, it would be interesting to see how many organizations that you think are noteworthy enough to belong here are not employers. Maybe a random sample. Can you post some numbers? -
i agree that employer should be un-cotyped.
check out the 'organisation types' and you'll find most of them are not employers http://www.freebase.com/view/organization/organization_type
cheers
-
this is a big deal and is really adding alot of wrong assertions. look at types that cotype organisation very few are employers. cub_scout_ group, fanclub, criminal_organisation it should really be uncotyped promptly.
-
Y'know, I think you're right. There was a time when we were thinking that "employer" and "employee" could be considered loosely enough to include employment-like relationships (such as an unpaid officer of an organization), but I think that that probably doesn't really work. I'll wait for any more comments before changing the model (OK, removing an included type isn't much of a schematic change, per se) just in case somebody objects.
-
-
-
There seem to have been 4 different copies of this person (two authors & two award winners) created by you a few days ago. I'm not sure if you were using a new tool or ran into a bug or what, but if you can remember what you were doing, you might want to try and track down any other duplicates which might be lurking.
-
-
-
Hi,
I see that the OSCON2009 home page at http://en.oreilly.com/oscon2009 features an impressive list of sponsors, I don't see anything, however, in the conference event schema, that would allow me to assert the sponsorship relationship between a conference event and a company.
Would it make sense to add a sponsor property to the conference event type ?
Thanks
-
Bringing Jeff and Bryan in on this... we were discussing a more general sponsorship model a couple of months back. Did that ever go anywhere?
-
A sponsorship model was promoted to the /business domain. See sponsor, sponsorship and sponsored recipient.
-
So, should Conference include the Sponsored Recipient type?
-
I'm guessing that most Conference Events are not sponsored in this sense, so my first impulse is "no", but it's not an especially strong impulse.
-
great idea ft.Conference series has a sponsorship property, but this should be optionally on conference event aswell.
im an admin on this (poorly admined) base, and will cotype 'Sponsored Recipient' and hide our sponsor property unless someone says i shouldnt.
-
Thanks for all your replies, as hinted by cheunger, I used the sponsor, sponsorship and sponsored recipient types to assert to assert the sponsorship relationship between OSCON2009 and a few companies.
I thought it had to be a fairly tedious affair to perform the appropriate co-typing and property filling, but the impressive fluidity of the UI made it quite an enjoyable experience.
Kudos to the Freebase team.
-
Looks like we're using "sponsor" in two different ways in this schema. The "sponsoring organization" of Conference Series is the organization that puts on the conference, rather than one that supports a conference financially (or through other means).
-
we could have each conference as a 'project', which has fundraising stuff....
-
-
-
Hi Jeff.
I'm new to FreeBase - just getting into it - researching the "Quotation" field for People - which is looks like you created. Wondering if I can ask you a question about it.My organization is about to have 1000s of people combing through news stories looking for statements that politicians have made about various topics such as envioronment, health care, budget, etc.
It occurred to me that we could contribute all of these attributions to Freebase. I'm wondering if the Quotation field is the proper place to put them. A sample entry might contain the following:
Person: Arnold Schwarzenegger
Subject: Environment
Quote: "We now know that what we've done in the past 100 years has caused such unbelievable damage to the world. We didn't know better, but now we do, and now it's not okay. There are certain things we know will happen in the next 30 to 40 years if we don't roll it back. So we have to start doing it now."
Source: http://money.cnn.com/magazines/fortune/fortune_archive/2007/04/02/8403410/index.htm
Can you point me in the right direction? Even better, to a simple API script that I could use to make these contributions?
-
Sorry I haven't been able to respond sooner. I think that Quotation is the right place for this kind of data. One possible issue is that "source" can't be a weblink -- "source" goes to a topic that represents the place the quotation appeared (in this case, probably an interview titled "The Governator's green agenda"). If you're just copying URLs, though, and not really going for the whole bibliographic nine yards, the URL could go into the "web links" property.
-
-
-
This Boscawen Public Library is currently flagged for merge with Boscawen Public Library topic.
One first is both a library and library system, but the second is a building. I don't think the library system type and the building or structure types are compatible.
Perhaps the former topic should be for the library system, and kept separate from the second topic which is the structure? (and the library type moved to the appropriate topic)
-
I agree that this probably should be more than one topic, but I'm not sure what the best way to organize them is. The idiom of combined library & library system seems to be used a lot for small one library "library systems," so splitting them all would be a fair amount of work for not a lot of benefit.
Colloquial usage by people tends to consider the library institution and the library structure to be one and the same, but it's really the same situation as museums where you can have a one room library in a building or libraries can move from building to building.
It's a modeling fidelity vs user confusion/work tradeoff that I don't feel strongly about one way or another, so I guess we should get Jeff or one of the Library admins to weigh in or make the call.
The choices are:
- One topic
- Three topics
- Library System/Library + Building
- Library System + Building/Library
-
I definitely support splitting the libraries from the library systems. I think the type is (or was) documented in such a way that the main branch of each system should be combined with the system itself, but that just seems confusing to me.
The building vs. thing the building is used for is a perennial problem, and not one we've ever really solved. What I'm leaning towards now would be to cotype the library (museum, embassy, etc.) with the building/building complex where appropriate (since as Tom points out there are lots of cases where the library/museum/whatnot might only take up part of a building). And also with the clear expectation that these combined topics will have to sometimes be split when the building user moves to a new location (which can result in the confusing situation where the now vacated building is still known as the library building, even though it now serves some other purpose). I guess that'd be a long-winded way of saying #4.
(I'm drawn to #2 for fidelity, but I also reconize that it would border on being unusable.)
-
#2 would be the best, but is overkill for most libraries.
#3 wouldn't work well for library systems which have multiple libraries (any national library, or large university library), and I agree with jeff that #4 would relate well with everyday use.
And another edge case - my library used to be in a van which would tour around the region. So no building involved at all :)
-
I should have clarified that my support of #3 was only for the library systems with a single library.
I'm happy with #4 as long as we're consistent about it.
-
-
-
I need Diocese and Archdiocese types for a list of Roman Catholic dioceses in Ireland. I see you have created these in the Anglicanism base... should I create separate Roman Catholic diocese types, or can we somehow make expand the existing types to include both Anglicanism and Roman Catholicism?
-
@rybesh, I've already been working on some generic types which should work with any religion. I've called the type Religious Jurisdiction. Let me know if you have any comments on the type.
@jeff - where did we get to with promoting these types to the commons?
-
There's been some work on a Religious Jurisdiction type recently. I think this is a much better general solution. It should get promoted to the Religion Commons soon, I think. There's a discussion about it here: http://www.freebase.com/view/guid/9202a8c04000641f800000000be1bdd2
-
Religious Jurisdiction looks perfect. Thanks!
-
Seems I can't use this yet. Is there some way to use a type before it's been promoted to the Commons?
-
It's sitting in my personal domain at the moment, so will still be considered a 'draft'.
I've now created a base http://religiousjurisdiction.freebase.com/
Let me know if it still doesn't work.
-
I think you have to add the reciprocal link from Religious Leader to Religious Leader Tenure.
-
Sorry, I had not seen Religious Leader is in Commons.
-
It's getting promoted: https://bugs.freebase.com/browse/DA-838
Thanks for pointing the need for the reciprocation. Hopefully the reciprocation will happen once the promotion is done.
-
I can use it now, sprocketonline. Thanks for your help.
-
@sproketonline: Sorry! -- the promotion task is in my queue, but the plotting out of the actual migration gives me a headache, so I keep putting it off. I'll get it moving along again.
-
Actually, this will be a bit more straightforward than I thought -- we can promote the Jurisdiction type and some of its properties with minimal fuss -- it's just part of the model relating to religious organization leadership that gets messy, since it will require a refactoring of the existing religious organization leadership CVT. I'll update the task(s).
-
Actually, I'm going to delay this -- the migration is too complex to do piecemeal. I've posted a query to the developers list about changing the expected type of /religious_organization_leadership/role to "Religious Leadership Title". Once we get buy-in for that, we can do the migration.
I'll reciprocate the religious organization property of jurisdiction, though, so that people can better use the type in the mean time.
-
I don't think anyone has queries that would be broken by this. Can we move ahead?
-
I hope to have this done in the next day or so.
-
DA-838 is complete - go crazy!
-
wibble
Thanks cheunger
-
-
-
I noticed there weren't too many properties in the soccer commons, so I had a go at creating my own schema in the football assocation base. I've emulated most of the types from the soccer commons; but my big addition is soccer match - which has properties for players, goal scorers, substitutions and bookings etc.. as an example I've filled in the FA Cup Final 1999
I'd appreciate any comments on the schema, I've tried to pick up previous comments gathered from the soccer base discussion; but I'm open to any ideas for improvements... (particularly competitions/leagues/seasons)
-
Congratulations, you are now an admin of the Soccer Commons :)
-
Thanks skud.
As much as I'd like to go crazy with my new powers and move everything to the commons, I'll hold back as I'd like some critical review of the types I mashed together in the association football base earlier today.
-
Well, since you asked... :) Bear in mind that I know exactly zilch about association football, other than which three English teams contain swear words in their names (which is what you learn when Billy Bragg is your main entree into the sport).
I notice that there is no direct relationship between players and teams (only via squad or match), and that in the case of Manchester United, you've co-typed it as both a squad and a team, which seems confusing based on the type descriptions.
Should soccer field include sports arena?
For goals, I think the disambiguator "team" is ambiguous -- at a glance it's not clear whether that's the player's team or the team the goal is credited to.
A soccer league does not seem to contain any teams.
Why is a soccer league also a soccer competition?
Soccer competition's property "seasons" expects "Event" rather than Soccer Soccer competion season.
Speaking of soccer competition season, the "matches" property should probably be reciprocated on the Match type.
But overall this is a very impressive schema!
-
Maybe add attendance to the soccer match type?
If possible, it'd be great if these types could inherit properly from the existing sports events/sports league championship events ..
i.e. a soccer match (is a) sports event (is an) event .. a soccer championship event (is a) sports league championship event (is a sports event) (is an) event ..and so on ..
I'd mainly like this to reduce data duplication across types, and to enable querying across sub-types i.e. give me all the sports events held at Wembley in 2008 (although I suppose this is possible at the moment, but there is some duplication of data required i.e. location, date/time etc)
Just to add:
The "sports league championship" type naming is probably misleading but the schema does fairly accurately describe all football cup events (Essentially the FA cup is a league championship for the FA associated teams, and the 1999 FA Cup Final was for the 2008-2009 FA Cup Season)
The biggest difference for football I can see is in the multi-format competitions (although these are similar to american sports which the sports event types seem to have been created for) where you start with a league format and then a set of play off matches to arrive at a single winner i.e. world cup, euros, champions league
-
>I notice that there is no direct relationship between players and teams (only via squad or match)
I've added a time-mediated property soccer player tenure.
>and that in the case of Manchester United, you've co-typed it as both a squad and a team, which seems confusing based on the type descriptions.
Now fixed, I've split the squad from the team.
>Should soccer field include sports arena?
now typed with sports facility.
>For goals, I think the disambiguator "team" is ambiguous
now called "point awarded to"
>A soccer league does not seem to contain any teams.
I've created soccer league participation which is time-mediated using seasons instead of dates.
>Why is a soccer league also a soccer competition?
This was where I was having issues. I'm trying to get my head around the Sports commons and also get some abstract inheritance in. I was trying to make league competitions different from cup competitions, and possibly different from multi-format competitions - yet all have a common inheritance from soccer competition.
>Soccer competition's property "seasons" expects "Event" rather than Soccer Soccer competion season.
fixed this.
>Speaking of soccer competition season, the "matches" property should probably be reciprocated on the Match type.
now reciprocated.
>If possible, it'd be great if these types could inherit properly from the existing sports events/sports league championship events ..
absolutely, my problem is that I'm not too familiar with the sports commons. But if you could point out which types to include, I'll update the schema. I've done soccer match now.
I've also added a schema for player transfers and loans.
All my types are still in association football, and I'd appreciate any further comments on the types. If we feel some of the types/properties are OK I will start replicating them in the soccer commons. (with the plan to eventually move everything over and delete association football).
-
I'm planning to move the schema from association football over the next few days.
If anyone has further comments or improvements to the schema, please let me know.
-
Job done! The schema is now up and running in the soccer commons.
Hopefully I got everything from football association across (I purposefully left out squads and competition season types as I think they're a bit flaky), but let me know if there's something wrong.
Ideas for the next feature are welcome :)
-
-
-
Are there any plans to add a property for Universal Product Codes or Global Trade Item Numbers? Seems like a useful property to have, and it could be applied to a lot of the topics on Freebase (computer games, comics, etc.)
-
yes. agree here.
there are many types of barcode systems thpough, so maybe it belongs in a seperate type?, which this type could eventually cotype.
i've got my hands on a big database of upc codes....
as long as this schema gets some +1's i'll upload it to this type this week.
-
GTIN is a property of consumer product. We used GTIN because UPC, EAN, and a few other barcode types are easily convertable to it.
-
-
-
jeff,
thought you might be interested in this one - I've created a base for common patterns in schemas. I'd noticed you'd used the word 'phylogeny' a lot in relation to schema design, and thought it might be a good idea to identify the types which have this.
What are your thoughts?
Iain
-
This is a cool idea. I was talking with Robert a little while back, and he's actually identified four different semantic patterns that use this schema design (that is, of types that have two properties that expect each other, there are four distinct relationships these represent).
1. Phylogeny: basically a hierarchical classification -- each topic is a member of a sub- or super-category. Organism classification is probably the canonical example.
2. Parent-child: each topic is begotten by (or begets) the other topics. The TV Episode spin-offs property is a non-biological example. (Organism is the other biological example.)
3. Sequence: you've already identified this
4. Containment: I can't think of any besides Location, but that doesn't mean they're not out there.
I tend to use "phylogeny" loosely when I'm talking about schemata to mean "two properties on a type that expect each other", since in terms of actual design there is no difference -- only in the ways humans interpret the patterns.
-
Wouldn't "Siblings" (single property linked to a CVT with a single property to indicate some form of equality) represent another type of relationship? Examples include Sibling relationship (of course) and the new Organization partnership.
-
Yes -- Iain's called it the Peer schema pattern. We usually call it a sibling relationship, but it's the same thing.
-
@ed, thanks for the example I've added it to the pattern. I've also renamed peer to sibling and added an alias.
@jeff Thanks for the input, I confused parent-child and phylogeny. I've made a new parent child type and renamed properties in phylogeny.
I'm still slightly unsure about the definitions, particularly the difference between phylogeny, parent/child and containment, so I've tried to define them in stricter terms using graph theory concepts:
- Phylogeny - It is a forest/directed acyclic graph. I'm still slightly confused about how it is used in freebase - it is a self reciprocating parent/child relationship. e.g. organism classification to organism classification. If it the property links two different types, it would be a parent/child. Also, if the property linking to the parent is unique, it wouldn't allow union between trees so isn't a forest graph, and is just a tree graph - therefore a containment pattern.
- Parent/Child - A directed acyclic graph/forest where topics are vertices and properties edges. Given my guess that a phylogeny is a parent/child between one type, this pattern is different by being between two types. i.e. the parent is a different type from the child. e.g. book to book edition.
- Sequence - an acyclic path graph
- Containment - In set theory, A is a proper subset of B. And would be a tree in graph theory. This would be a self reciprocating property, otherwise it is a parent/child pattern.
- Sibling - graphs between topics of the same type, with a definition of some sort of equality between linked topics. I was going to suggest it be a complete graph based on the /people/siblings, but realised that wouldn't necessarily work for step families or /influence_node/peers.
I think this makes sense, and if these concepts are OK I'll update the descriptions on the pattern CVTs.
Given the graph theory rules, it would be possible to run a bot and identify topics for data gardening, or identify types/properties which follow these patterns based on their current use in freebase.
-
my definition of phlogeny being distinct from a parent/child purely based on whether a property is self-reciprocated on the same type, or is reciprocated on a different type doesn't feel right.
Under that definition it means that the relationship between /people/person/parents and /people/person/children is a phylogeny rather than a parent/child relationship....
Not intuitive, but perhaps logically OK?
Otherwise the seperation between phylogeny and parent-child patterns would have to be based entirely on whether the topic is an abstract concept e.g. organism classification, or is a real object e.g. person. And that's a whole other rabbit hole.
gaah! *head explodes*
-
Note that I didn't make up these distinctions, so I accept no credit or blame for them. :)
Re phylogeny vs. parent-child: it does seem to fall into abstract vs. concrete, doesn't it? I think there is a logical difference between the relationship of a partent to a child and a genus to a species, however: a genus is a category that comprises one or more species; a parent is not a category, and does not comprise any children. To take this away from people, the "spin-off/spun off from" properties of Company are a parent/child pattern, but the "parent company/subsidiary companies" properties are a phylogeny (although in this case, a date-mediated one).
Note that species are also proper subsets of genuses, so I don't think that that can be the distinguishing factor between phylogeny and containment.
Properties linking two different types are an interesting point: these can follow the same semantic patterns as any of the ones listed above, but are inherently limited in number of steps, rather than open-ended, which is what we've largely been discussing here. (So Adaptation/Adapted Work is a parent/child relationship; Country/Administrative Division is containment; etc.)
-
properties of two different types -> I've tweaked the phylogeny, parent/child and containment types so they can have 2 different types (one for the parent type, and one for the child type). If a type is self-reciprocating, the same type would appear in both properties.
phylogeny vs parent/child -> Agreed phylogeny is for abstract categories, parent/child for the concrete. both super & sub* of a phylogeny are abstract categories/sets.
phylogeny and containment -> if phylogeny is for abstract categories which can contain other abstract categories, then containment is for the concrete/physical which can contain other concrete/physical? e.g. location/location or building complex/building.
* BTW I'm using super/sub in place of parent/child as a way of differentiating when speaking about phylogeny.
-
As the properties on phylogeny, parent/child and containment are now all the same (parent type, parent->child property, child type, child->parent property); I'm tempted to normalise and just have one type for all three patterns, but include an additional property called "pattern variation".
This property would allow for differentiation between the patterns by selecting phylogeny, parent/child or containment from an enumeration.
-
-
-
-
hi jeff, can you help me model Criminal Conviction? i'm stuck on trying to do jail time information like a 10-year sentence and things.
I have it set up now as a cvs inside a cvs, but i dont think it likes that. It doesnt show up in the editor, bugs out when i try to edit it in detail view. Same thing for fines, community service too i think probably. how would you do this if you were me?
-
-
-
I think an abstract type should be fairly simple. The primary properties are:
1. A name or title (the same as the article being abstracted).
2. One to two paragraphs for text.
Of course, we also need to be able to move back and forth between the abstract and the article that it is abstracting.
The abstract structure from DocBook is probably the best example to use for properties in an abstract. That structure is documented at http://www.docbook.org/tdg/en/html/abstract.html.
Some more descriptive information about what abstracts should be is at:
http://www.rpi.edu/web/writingcenter/abstracts.html
http://leo.stcloudstate.edu/bizwrite/abstracts.html
Let me know if you have any additional questions.-
That looks pretty straightforward. The big question is, what type should it connect to? "Published Work" is the most general type for publishing, but since it includes books (of any type), stories, poems, essays, etc., as well as articles and non-fiction books, it seems a bit odd to put it there. On the other hand, I'm reluctant to add another type called "abstracted publication" (or something) that could be added as a co-type to any work that needed to have an abstract attached. Any thoughts?
-
I'm trying to think through how these various types are related to each other.
My thinking is that there is an Article type (perhaps your Published Work type). An article would be a type related to Periodical/Magazine, and an Abstract would be part of an Article. The relationships would be something like:
Magazine > Article > Abstract
Of course, there would be other types included within these.
There clearly needs to be a linkage back and forth between these various types so that a user is able move from magazine to abstract to article. Unfortunately, I'm not familiar enough with Freebase to say how this should be implemented.
-
-
-
Do you have any plans to put together an "Abstract" type for inclusion in the publishing domain? I'm currently putting together a series of types and need to include an "Abstract" as a property for a couple of them. If possible, I'd like to keep that type in the publishing domain rather than in the area that I'm working on.
-
I hadn't thought about it, but it seems like a possibility. I know that the publishing domain doesn't currently have good models for academic/scientific publications, although I have been talking to some people about that, and it seems like "abstract" might fit in with that conversation. What properties do you think should go on it?
-
-
