Recent Changes for "Semantic Wiki" - Sycamore Wiki

Semantic Wiki

JasonAller — 2010-02-15 23:39:53

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 290:	Line 290:
	+ ------ + ''2010-02-15 23:39:53'' [[nbsp]] Notes on derived metadata sets... + + Instead of single fields start with a base metadata form that consists of things that will need to be tracked about all pages: + * Page Name -- Changing this effects a page rename? + * on Wiki -- to allow moving pages between wikis. Links get rewritten as part of a move and as part of a revert? + + Then from this create some metadata that uses this base, but adds groups of appropriate fields. At the first tier it is just separating pages out into general classes, but eventually you'd have (base -> business -> restaurant -> sushi) with each level adding appropriate new fields. + + Fields should allow radio buttons, checkboxes, text, numeric, regex validated, range (for prices), date time, time matrixes (for open hours), photos. each field should track if it is required or not, and allow for a default value. + + In the same way that people can now create templates allow for the creation of metadata sets. only admins will be able to remove fields from a set because doing so would remove that data from all pages that use that metadata set. alternatively have a central library of metadata that any wiki can subscribe to. + + It becomes very easy to produce reports off the information. (base -> business -> contractor -> painting) for instance would allow any page using that set to see at a glance all of the contractors, their license numbers, and their price ranges and ratings automatically. It should report for the local wiki first and then report separately for nearby wikis with an option to view the same information across all wikis. --["Users/JasonAller"]

Semantic Wiki

PalestitneFeed — 2009-06-01 02:12:41

(quick edit)

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 5:	Line 5:
- The word [http://en.wikipedia.org/wiki/Semantics Semantic] is related to the meaning carried by an any communication in words, code, drawing, anything. The idea of Semantic Wiki (or semantic web) is to write or create information in a way that make it easy to process and use by software agents. Many people use the term Semantic data and metadata interchangeably. In the case of Semantic Wiki it means to giving richer meaning to data managed via a user-maintained website or wiki. Both mean information about information. Semantic data can be expressed in a set of exactly three pieces of data. Together these pieces are called statements.	+ The word [http://en.wikipedia.org/wiki/Semantics Semantic] is related to the meaning carried by any communication in words, code, drawing, anything. The idea of Semantic Wiki (or semantic web) is to write or create information in a way that make it easy to process and use by software agents. Many people use the term Semantic data and metadata interchangeably. In the case of Semantic Wiki it means to giving richer meaning to data managed via a user-maintained website or wiki. Both mean information about information. Semantic data can be expressed in a set of exactly three pieces of data. Together these pieces are called statements.

Semantic Wiki

PhilipNeustrom — 2008-04-07 03:02:12

apartments

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 45:	Line 45:
	+ Integrated w/ mapping, a'la a map for [wiki:davis:"Apartments"]. Map of all pages with a given tag / value. +

Semantic Wiki

PhilipNeustrom — 2007-10-17 00:59:47

(quick edit)

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 221:	Line 221:
- == Mockup ===	+ == Mockup ==

Semantic Wiki

PhilipNeustrom — 2007-10-17 00:59:36

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 221:	Line 221:
	+ == Mockup === + ''UI mockup goes here'' +

Semantic Wiki

PhilipNeustrom — 2007-04-26 00:54:13

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 13:	Line 13:
- When data has meaning to both a machine and a person wonderful things can happen. What social networking sites like [http://www.myspace.com MySpace] have done to the dating scene and to personal relationships, the semantic web will do to all electronically stored information. You will be able to submit metadata queries like show me all objects of type "restaurant" that are open after midnight less than 5 miles from my home.	+ When data has meaning to both a machine and a person wonderful things can happen. What social networking sites like [http://www.myspace.com MySpace] have done to the dating scene and to personal relationships, the semantic web will do to all electronically stored information. You will be able to submit metadata queries like show me all objects of type "restaurant" that are open after midnight less than 5 miles from my home. And, seriously, don't you want a god damn hamburger at 2AM?

Semantic Wiki

PhilipNeustrom — 2007-04-23 05:01:51

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 284:	Line 284:
- I'm not sure about other semantic projects. A lot of projects including [http://wiki.ontoworld.org/wiki/Semantic_MediaWiki SemanticMediaWiki] use [wiki:wikipedia:XSD XSD] to define their data types. As far as searching by geo location, I've not seen how it's done in the backend. We could use the [http://dev.mysql.com/doc/refman/5.0/en/cast-functions.html casting functions] to mold the data into what we wanted it to be. Of course then we could use something [http://ben.milleare.com/2006/09/03/calculating-distance-with-latitude-and-longitude/ like this] to calculate distance between objects.	+ I'm not sure about other semantic projects. A lot of projects including [http://wiki.ontoworld.org/wiki/Semantic_MediaWiki SemanticMediaWiki] use [wiki:wikipedia:XSD XSD] to define their data types (defining and storing are different, though). As far as searching by geo location, I've not seen how it's done in the backend. We could use the [http://dev.mysql.com/doc/refman/5.0/en/cast-functions.html casting functions] to mold the data into what we wanted it to be. Of course then we could use something [http://ben.milleare.com/2006/09/03/calculating-distance-with-latitude-and-longitude/ like this] to calculate distance between objects.

Semantic Wiki

Sc0ttBeardsley — 2007-04-23 04:08:08

casting in mysql and geo distance link comment

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 283:	Line 283:
	+ + I'm not sure about other semantic projects. A lot of projects including [http://wiki.ontoworld.org/wiki/Semantic_MediaWiki SemanticMediaWiki] use [wiki:wikipedia:XSD XSD] to define their data types. As far as searching by geo location, I've not seen how it's done in the backend. We could use the [http://dev.mysql.com/doc/refman/5.0/en/cast-functions.html casting functions] to mold the data into what we wanted it to be. Of course then we could use something [http://ben.milleare.com/2006/09/03/calculating-distance-with-latitude-and-longitude/ like this] to calculate distance between objects.

Semantic Wiki

PhilipNeustrom — 2007-04-23 03:35:12

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 282:	Line 282:
- How do other semantic projects deal with this issue?	+ How do other semantic projects deal with this issue? One possible solution is to not allow sorts of generic types. Instead, we allow sorts of types that have accompanying python extensions that tell us what to do. E.g. dates.py tells us how to sort dates and how to store dates (we create and use a separate table), times.py tells us how to input and query for times, and geo.py tells us how to input and query for latitude/longitude. We would still update and use the tables we have now, but when we're querying against or inputting a type with an associated set of rules we follow those. (We use both tables for input, and use the native table for queries). --["Users/PhilipNeustrom"]

Semantic Wiki

PhilipNeustrom — 2007-04-23 03:31:05

(quick edit)

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 282:	Line 282:
- How do other sematic projects deal with this issue?	+ How do other semantic projects deal with this issue?

Semantic Wiki

PhilipNeustrom — 2007-04-23 03:30:57

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 281:	Line 281:
	+ + How do other sematic projects deal with this issue?

Semantic Wiki

Sc0ttBeardsley — 2007-04-23 03:27:14

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 279:	Line 279:
	+ ------ + ''2007-04-23 03:27:14'' [[nbsp]] ''You bring up a good point Philip. It would be best to store spatial data using spatial extensions to MySQL/Postgres. Do you have any suggestions? Perhaps a separate table for each type?'' --["Users/Sc0ttBeardsley"]

Semantic Wiki

PhilipNeustrom — 2007-04-23 03:18:21

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 278:	Line 278:
- ''2007-04-23 03:06:35'' [[nbsp]] Given the schema here, how would we search for something based on location without getting all of the locations in the database and scanning through them? Will string sorts/indexes be sufficient for our efficiency purposes, given that we keep all values in a consistent format in the DB? This is just an example problem. --["Users/PhilipNeustrom"]	+ ''2007-04-23 03:06:35'' [[nbsp]] Given the schema here, how would we search for something based on location without getting all of the locations in the database and scanning through them? Will string sorts/indexes be sufficient for our efficiency purposes, given that we keep all values in a consistent format in the DB? In what cases would we run into problems with this approach? This is just an example problem. --["Users/PhilipNeustrom"]

Semantic Wiki

PhilipNeustrom — 2007-04-23 03:15:42

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 278:	Line 278:
- ''2007-04-23 03:06:35'' [[nbsp]] Given the schema here, how would we search for something based on location without getting all of the locations in the database and scanning through them? This is just an example problem. --["Users/PhilipNeustrom"]	+ ''2007-04-23 03:06:35'' [[nbsp]] Given the schema here, how would we search for something based on location without getting all of the locations in the database and scanning through them? Will string sorts/indexes be sufficient for our efficiency purposes, given that we keep all values in a consistent format in the DB? This is just an example problem. --["Users/PhilipNeustrom"]

Semantic Wiki

PhilipNeustrom — 2007-04-23 03:07:37

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 275:	Line 275:
	+
Line 277:	Line 278:
- ''2007-04-23 03:06:35'' [[nbsp]] Given the schema here, how would we search for something based on location without getting all of the locations in the database and scanning through them? --["Users/PhilipNeustrom"]	+ ''2007-04-23 03:06:35'' [[nbsp]] Given the schema here, how would we search for something based on location without getting all of the locations in the database and scanning through them? This is just an example problem. --["Users/PhilipNeustrom"]

Semantic Wiki

PhilipNeustrom — 2007-04-23 03:06:35

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 276:	Line 276:
	+ ------ + ''2007-04-23 03:06:35'' [[nbsp]] Given the schema here, how would we search for something based on location without getting all of the locations in the database and scanning through them? --["Users/PhilipNeustrom"]

Semantic Wiki

2007-04-23 02:00:31

added an idea about syntax

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 265:	Line 265:
	+ ------ + More ideas about using a macro with a body (or some king of in-page metadata block): + {{{ + [[metadata(display=False)]] + \|\| name \|\| Joe \|\| firstName \|\| + \|\| phone \|\| (555)555-5555 \|\| phoneNumber \|\| + \|\| address \|\| 123 Main Street \|\| streetAdress \|\| + \|\| number of pets \|\| 14 \|\| int \|\| + [[metadata]] + }}} + Most users will already know how to make tables. If they don't put in the last column, just use a default, which could be derived from the name in many cases. --["Users/StephenDay"]

Semantic Wiki

PhilipNeustrom — 2007-04-22 23:46:14

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 190:	Line 190:
	+ See ["/Caching"] for thoughts about making this fast. +

Semantic Wiki

JasonAller — 2007-04-22 02:34:17

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 2:	Line 2:
	+ + [[TableOfContents(right)]]
Line 45:	Line 47:
	+ see ["/API"] for one possible inplementation +

Semantic Wiki

PhilipNeustrom — 2007-04-22 01:17:28

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 257:	Line 257:
	+ + Using the not-in-pagetext-form we can have the "Tag" or "name" (whatever we end up calling it) field cause the second field to change once it's entered (javascript magic)..

Semantic Wiki

Sc0ttBeardsley — 2007-04-21 23:27:53

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 255:	Line 255:
	+ ------ + ''2007-04-21 23:27:53'' [[nbsp]] ya, that should work, but I'm worried about how we'll be adding a new tag/name though. I guess it'll be OK to just allow new tags and just set their type to the default (which is as a string). Since every tag/name has a specific type you'll want a way to define this when adding the tag/name. Also, just a note on why every tag/name should have a specific type: this will enable a uniform display of that name. So phone numbers will always be displayed as: '''+1 (XXX) XXX-XXXX''' --["Users/Sc0ttBeardsley"]

Semantic Wiki

StephenDay — 2007-04-21 12:28:12

fixed formatting

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 250:	Line 250:
- [[metadata(hide)]]	+ {{{[[metadata(hide)]]
Line 254:	Line 254:
- [[metadata]] - --24.201.230.79	+ [[metadata]]}}} --["Users/StephenDay"]

Semantic Wiki

2007-04-21 12:23:12

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 248:	Line 248:
	+ ------ + ''2007-04-21 12:23:12'' [[nbsp]] You could have the "metadata" entered directly on the page in some sort of metadata block. That block could have a bunch of display options including "hide". This way the user would he able to use {{{[[get(address)]]}}} if they needed and not bet redundant. In the Confluence wiki system the metadata "block" is simply a macro with a body: + [[metadata(hide)]] + name = Joe + phone = (555)555-5555 + address = 123 Main Street + [[metadata]] + --24.201.230.79

Semantic Wiki

PhilipNeustrom — 2007-04-21 06:45:16

some more thoughts

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 207:	Line 207:
	+ There are a few different ways of dealing with the display of the metadata. One is to embed the data directly into the page content, in the same way things like links and macros are embedded in a page's text. All data entered would be displayed right where it was entered. + + Another way is to have data entered into the page's body (or via a separate interface), but then only displayed when it was signaled by some sort of {{{[[get(value)]]}}} macro. This has the advantage of ultimate control over the presentation of the information. It has the drawback of making it potentially confusing to change the data -- how does the average joe know how to change the address of the page? What used to be just "300 Main Street" is now {{{[[get(address)]]}}}. This confusion could probably be mitigated by displaying the metadata fields right in the edit interface, and when initiating a [wiki:wikispot:"quick edit"] on the area, somehow entering into an edit for just that metadata field.. + + Another way is to have the data entered and displayed in a way that's separated from the page's body (e.g. at the bottom of the page). This has the advantage of making it easy to see ''where'' to change the information -- you change it right where it's displayed -- but it has the disadvantage of not allowing for careful control over where the data is displayed, and being redundant (the address will still probably be entered on the page). We could still allow for something like {{{[[get(value)]]}}} in this case.. + + ''I'm leaning toward thinking the last option here is the best, UI wise. It may not be super pretty, but I think it's the most obvious.'' --["Users/PhilipNeustrom"] +

Semantic Wiki

PhilipNeustrom — 2007-04-21 01:18:53

added example

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 238:	Line 238:
	+ + We'll talk more, but just as an idea here's what flickr does to solve the "figure out what tag to use" issue: [[Image(type_tag_flickr.png)]] [[Image(choose_tag_flickr.png)]]

Semantic Wiki

PhilipNeustrom — 2007-04-21 01:17:33

Upload of image choose_tag_flickr.png.

Semantic Wiki

PhilipNeustrom — 2007-04-21 01:17:18

Upload of image type_tag_flickr.png.

Semantic Wiki

Sc0ttBeardsley — 2007-04-21 01:11:51

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 236:	Line 236:
	+ ------ + ''2007-04-21 01:11:51'' [[nbsp]] Ahh yes, I see where you're going Philip. I kinda like the separate metadata interface. I think there would have to be a drop down menu for the "tag" field as it is labeled in the UI screenshot. We should talk more about this though. --["Users/Sc0ttBeardsley"]

Semantic Wiki

PhilipNeustrom — 2007-04-20 20:54:38

bit more ui ideas

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 205:	Line 205:
	+ Or maybe we should show all the metadata stuff in the normal editor interface, keeping everything in the same place. We could also make it so that wherever we display the data we allow it to be clicked on and edited, inline-style. +

Semantic Wiki

PhilipNeustrom — 2007-04-20 20:48:36

added flawed example, but it's important to think about UI here

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 200:	Line 200:
	+ = User interface = + The UI for all of this is really important. We need to keep it just as easy as it is now for people to change addresses, phone numbers, and so forth. + + [[Image(metadata_button.png, thumbnail, "One option would be to have a button that reads 'Metadata' in the edit area.")]] [[Image(metadata_edit.png, thumbnail, "One option for editing metadata.")]] +

Semantic Wiki

PhilipNeustrom — 2007-04-20 20:47:51

Upload of image metadata_edit.png.

Semantic Wiki

PhilipNeustrom — 2007-04-20 20:47:36

Upload of image metadata_button.png.

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 07:34:46

(quick edit)

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 122:	Line 122:
- This table is for associating a particular data type to a "name" or "predicate". An example predicate is a phone number. In the example below the predicate class:phone is of type integer. Phone numbers can be stored as just numbers (ie 916123456) and they can be parsed into a readable format (ie (916) 123-4567) as needed. The following types are expected to be supported:	+ This table is for associating a particular data type to a "name" or "predicate". An example predicate is a phone number. In the example below the predicate class:phone is of type integer. Phone numbers can be stored as just numbers (ie 9161234567) and they can be parsed into a readable format (ie (916) 123-4567) as needed. The following types are expected to be supported:

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 04:17:34

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 227:	Line 227:
	+ ------ + ''2007-04-20 04:17:34'' [[nbsp]] A comment about types: I think we should offload the type of a metadata item onto another '''special''' page. Instead of having the page editor define the type of a metadata item inline it should be a separate procedure. This makes it slightly more difficult (not impossible) to add new vocabulary words. The goal is to get people to use a small set of words to describe data. If we tie type to the predicate (aka keyword aka name) elsewhere then we can both limit the syntax required for the page editors while still knowing what type of data they should be entering. So the '''special''' page will allow page editors to add a new vocabulary word (and it's type) on the fly. This will essentially be an interface to the type table. --["Users/Sc0ttBeardsley"]

Semantic Wiki

PhilipNeustrom — 2007-04-20 04:10:16

linked far's tags thing

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 198:	Line 198:
	+ * [http://farmckon.rottenchester.com/Front_Page Far's Sycamore Tag sketchup]. He's been playing with the idea of a tagging system for the wiki. Regardless of the outcome, the tags system should become a subset of the semantic efforts here. Perhaps we could even use a "tags" interface for adding metadata to a page -- a'la flickr (a box, you click, type a value, press return). More complex relationships could be expressed by typing in the "type key := value" form of a "tag." For better or for worse, people are accustomed to the idea of a "tag" now, and using "tag" is more general than "category."

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 04:09:32

cleaned up examples a bit

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 43:	Line 43:
- == Possible syntax == - - Possible formats for relations: - * A relation: {{{[[Meta(class:business_type,Restaurant)]]}}} - * {{{class:business_type:=Restaurant}}} (general form is predicate_alias:predicate := object and the subject is extracted automatically) - - Possible formats for attributes: - * {{{[[Meta(class:phone,"(916) 123-4567")]]}}} - * {{{class:phone := (916) 123-4567}}} (general form is predicate_alias:predicate := literal_value) - * {{{class:tag := neighborhood}}} - * {{{class:point := -123.456, 54.23}}}	+ == Unified Syntax Examples == + + Possible formats for either a relation or attribute (the unified syntax): + + === Wiki Page Links === + + The following examples link a wiki page to another wiki page and gives that link a specific meaning. + * {{{[business_type := Restaurant]}}} (this uses the default namespace: class) + * {{{[class:business_type := Restaurant]}}} (this explicitly sets the vocabulary namespace) + + === Literal Values and Offsite Links === + + The following examples link a wiki page to an off-site URL or describes something about the current page. + * {{{[phone := (916) 123-4567]}}} (this uses the default namespace: class) + * {{{[class:phone := (916) 123-4567]}}} (explicitly sets the namespace) + * {{{[tag := neighborhood]}}} + * {{{[location := -123.456, 54.23]}}}
Line 58:	Line 64:
- - == Statement Examples == - - * John's Phone Number is (916) 123-4567 - * John's Last Name is Smith - * Generic form: <subject> <predicate> <object> or could equivalently be thought of as <key> <type> <value>.

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 03:57:10

fixed delta of venus example with new unified syntax

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 31:	Line 31:
- * Longitude/Latitude (attributes): [[Location:=Point(-12.34,23.456)]] - * Neighborhood (a relation): [LocatedIn:=Link("Downtown Davis")] <- This could be calculated once we have the long/lat and the boundaries of "Downtown Davis"	+ * Longitude/Latitude (attributes): [location:=-12.34,23.456] + * Neighborhood (a relation): [district:=Downtown Davis] <- This could be calculated once we have the long/lat and the boundaries of "Downtown Davis"
Line 34:	Line 34:
- * [HoursOpen:=DatetimeRange(M-W,0800,2200)] <- These would probably need to be generated by a special UI for usability reasons - * [HoursOpen:=DatetimeRange(R-F,0800,0000)] - * [HoursOpen:=DatetimeRange(S,0800,1400)] - * [HappyHour:=DatetimeRange(M-F,1500,1800)] - * Phone: [Phone:=Phone("(530) 753-8639")] - * Email: [Email:=Email("info@deltaofvenus.org")] - * Website: [Website:=URL("http://deltaofvenus.org")] - * Est: [Established:=Date("1990-01-01")] - * Menu (a relation): [Menu:=Link("Delta of Venus/Menu")] - * Type/Category/Label (a relation or attribute it could be either): [IsA:=Link("Restaurant")]	+ * [hours:=Monday through Wednesday 8am to 10pm, Thursday through Friday 8am to midnight, Saturday 8am to 2pm] <- These would probably need to be generated by a special UI for usability reasons + * [happyHours:=Monday through Friday 3pm to 6pm] + * Phone: [phone:=(530) 753-8639] + * Email: [email:=info@deltaofvenus.org] + * Website: [website:=http://deltaofvenus.org] + * Est: [established:=January 1st, 1990] + * Menu (a relation): [menu:=Delta of Venus/Menu] + * Tag, Label or Category: [tag:=restaurant]

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 03:49:03

fixed predicate to avoid confusion with the geoPoint type

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 55:	Line 55:
- * {{{class:geoPoint := -123.456, 54.23}}}	+ * {{{class:point := -123.456, 54.23}}}

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 03:46:40

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 226:	Line 226:
	+ ------ + ''2007-04-20 03:46:40'' [[nbsp]] re: metadata button: I was thinking of just embedding it into the text of a page. The metadata wouldn't have to be displayed by default. Say you have a macro called '''Metadata''' that takes 4 args (predicate_alias,predicate,value,display_flag). This macro would add an entry to the metadata table, then if the display_flag is set it would display the metadata in a predefined format (based on the type of the predicate). For example I have a restaurant page with the following macro call: {{{Metadata(class,tag,expensive)}}}. This would add the metadata about this restaurant being expensive but it would not display that information on the final page. As far as getting a list of valid predicate_aliases and predicates, yes it might be nice to have some sort of tool (ajax?) that will pull up the already defined vocabularies. It is important to have something like this because we want everyone speaking the same language. --["Users/Sc0ttBeardsley"]

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 03:38:03

added table descriptions and updated possible syntax

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 48:	Line 48:
- * A relation: {{{[[Relation(CURRENTPAGE,is_a,Restaurant)]]}}} - * {{{is_a::Restaurant}}} (general form is predicate::object and the subject is extracted automatically)	+ * A relation: {{{[[Meta(class:business_type,Restaurant)]]}}} + * {{{class:business_type:=Restaurant}}} (general form is predicate_alias:predicate := object and the subject is extracted automatically)
Line 52:	Line 52:
- * {{{[[Attribute("Phone Number","(916) 123-4567")]]}}} - * {{{PhoneNumber := (916) 123-4567}}} (general form is Type Subject := Value) - - With this form, we can explain the idea to newcomers as a way of "tagging the page with a value," in a sense.	+ * {{{[[Meta(class:phone,"(916) 123-4567")]]}}} + * {{{class:phone := (916) 123-4567}}} (general form is predicate_alias:predicate := literal_value) + * {{{class:tag := neighborhood}}} + * {{{class:geoPoint := -123.456, 54.23}}} + + With this form, we can explain the idea to newcomers as a way of "tagging the page with a value," in a sense. Since each predicate has a pre-defined type (managed via a special page) there is no need to explicitly state the type.
Line 58:	Line 60:
- - ''see also: [http://meta.wikimedia.org/wiki/Semantic_MediaWiki/Blueprint MediaWiki's Blueprint page]''
Line 84:	Line 84:
- This is a table is already a part of the Sycamore schema. It is shown here for illustrative purposes. Here are some sample rows:	+ This table is already a part of the Sycamore schema. It is shown here for illustrative purposes. Here are some sample rows:
Line 99:	Line 99:
	+ This table provides a way to store multiple namespaces (or vocabularies) in a single wiki. The most used entries in this table are class, literal, and wiki. It is a good idea to try to use other namespaces like foaf, dc, etc but it should be up to the community to enforce these rules. These namespaces will likely be imported on initial installation (or upgrade). There doesn't necessarily need to be a way to add namespaces (yet).
Line 123:	Line 124:
	+ This table is for associating a particular data type to a "name" or "predicate". An example predicate is a phone number. In the example below the predicate class:phone is of type integer. Phone numbers can be stored as just numbers (ie 916123456) and they can be parsed into a readable format (ie (916) 123-4567) as needed. The following types are expected to be supported: + * integer + * string + * float + * geoPoint + * geoLine + * geoArea + * currency + * wikipage + * url + * datetime + * datetime range +
Line 139:	Line 153:
- This table defines metadata for pages stored in the wiki. This table follows the subject-predicate-object rule because the page id (or pagename) is the subject.	+ This table defines metadata for pages stored in the wiki. This table follows the subject-predicate-object rule because the pagename is always the subject.
Line 181:	Line 195:
	+ * [http://meta.wikimedia.org/wiki/Semantic_MediaWiki/Blueprint MediaWiki's Blueprint page]

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 03:18:50

updated table examples

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 82:	Line 82:
- ==== page ==== - - This is a table with all pages in the wiki. Here is an example row: - {{{ - +---------------+ - \| pagename \| - +---------------+ - \| Shakey's Pizza \| - +---------------+ - }}} - - This can easily be changed to use the current Sycamore standard which is to use the pagename as the unique id.	+ ==== curPages ==== + + This is a table is already a part of the Sycamore schema. It is shown here for illustrative purposes. Here are some sample rows: + {{{ + +--------------------+ + \| pagename \| ... + +--------------------+ + \| East Sacramento \| ... + +--------------------+ + \| Sacramento \| ... + +--------------------+ + \| California \| ... + +--------------------+ + }}}
Line 98:	Line 100:
- +----+---------+---------------------------------------+ - \| id \| alias \| uri \| - +----+---------+---------------------------------------+ - \| 0 \| literal \| \| - +----+---------+---------------------------------------+ - \| 1 \| link \| http://daviswiki.org/wiki/ \| - +----+---------+---------------------------------------+ - \| 2 \| att \| http://daviswiki.org/wiki/Attributes/ \| - +----+---------+---------------------------------------+ - \| 3 \| dc \| http://purl.org/dc/terms/ \| - +----+---------+---------------------------------------+ - }}} - - ==== attribute ==== - - This table defines attributes for objects stored in the wiki. Every page is an object. This table follows the subject-predicate-object rule because the page id (or pagename) is the subject. Here is an example phone number attribute for the '''Shakey's Pizza''' page. - {{{ - +-----+----------------+----------------+------------+----------------+--------------+ - \| id \| pagename \| predicate_nsid \| predicate \| object_nsid \| object \| - +-----+----------------+----------------+------------+----------------+--------------+ - \| 654 \| Shakey's Pizza \| 3 \| isPartOf \| 1 \| Restaurants \| - +-----+----------------+----------------+------------+----------------+--------------+ - \| 655 \| Shakey's Pizza \| 2 \| PhoneNumber\| 0 \| 9161234567 \| - +-----+----------------+----------------+------------+----------------+--------------+ - }}} - - In this case the subject is the Shakey's Pizza page, the predicate is '''PhoneNumber''' and the object is "9161234567". Since this data will be managed from the Shakey's Pizza page there is no need to store the full namespace or even a link to it. This table can also hold relations or references to other wiki pages. If the object_nsid is 1 (the id that matches the wiki baseurl) than the object is a link and can be made into an href to the actual page.	+ +-----------+---------------------------------------------+ + \| alias \| uri \| + +-----------+---------------------------------------------+ + \| class \| http://wikispot.org/class/ \| + +-----------+---------------------------------------------+ + \| literal \| http://wikispot.org/literal# \| + +-----------+---------------------------------------------+ + \| wiki \| http://sacramento.wikispot.org/ \| + +-----------+---------------------------------------------+ + \| dc \| http://purl.org/dc/elements/1.1/ \| + +-----------+---------------------------------------------+ + \| dcterms \| http://purl.org/dc/terms/ \| + +-----------+---------------------------------------------+ + \| wikipedia \| http://en.wikipedia.org/wiki/ \| + +-----------+---------------------------------------------+ + \| rdf \| http://www.w3.org/1999/02/22-rdf-syntax-ns# \| + +-----------+---------------------------------------------+ + \| rdfs \| http://www.w3.org/2000/01/rdf-schema# \| + +-----------+---------------------------------------------+ + }}} + + ==== type ==== + + {{{ + +-------+----------------------------+ + \| alias \| name \| type \| + +-------+----------------------------+ + \| class \| phone \| integer \| + +-------+----------------------------+ + \| class \| neighborhood_of \| wikipage \| + +-------+----------------------------+ + \| class \| city_in \| wikipage \| + +-------+----------------------------+ + \| class \| tag \| string \| + +-------+----------------------------+ + }}} + + ==== metadata ==== + + This table defines metadata for pages stored in the wiki. This table follows the subject-predicate-object rule because the page id (or pagename) is the subject. + {{{ + +----+-----------------+-----------------+-----------------+----------------+--------------+ + \| id \| pagename \| predicate_alias \| predicate \| object_alias \| object \| + +----+-----------------+-----------------+-----------------+----------------+--------------+ + \| 1 \| sacramento \| class \| city_in \| wiki \| California \| + +----+-----------------+-----------------+-----------------+----------------+--------------+ + \| 2 \| east sacramento \| class \| neighborhood_of \| wiki \| Sacramento \| + +----+-----------------+-----------------+-----------------+----------------+--------------+ + \| 3 \| east sacramento \| class \| tag \| literal \| neighborhood \| + +----+-----------------+-----------------+-----------------+----------------+--------------+ + }}}
Line 128:	Line 154:
- This feature requires changes to certain user interfaces.	+ This feature requires some changes to the user interface.
Line 146:	Line 172:
- This feature should be able to be implemented as a plugin but it does require database changes and extra search capabilities.	+ This feature should be able to be implemented as a plugin but it does require database changes and extra search capabilities. There will need to be a few custom pages including one to allow adding entries to the type table.

Semantic Wiki

PhilipNeustrom — 2007-04-20 03:08:19

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 182:	Line 182:
- ''2007-04-20 03:06:49'' [[nbsp]] I like the simplier schema. We should talk a bit about markup and UI. [Established:=Date("1990-01-01")] versus Date Established := 1990-01-01, . If we say a type can only be one word then the latter markup would work well, I think?	+ ''2007-04-20 03:06:49'' [[nbsp]] I like the simplier schema. We should talk a bit about markup and UI. [Established:=Date("1990-01-01")] versus Date Established := 1990-01-01. If we say a type can only be one word then the latter markup would work well, I think?
Line 184:	Line 184:
- We could also opt to have this as a somewhat disjoint UI from the normal editing interface. I'm really not sure how the UI for all of this ought to work, but I think it's actually the most important part, as we have to make this easy to use (otherwise it won't be used). --["Users/PhilipNeustrom"]	+ We could also opt to have this as a somewhat disjoint UI from the normal editing interface (a "Metadata" button?). I'm really not sure how the UI for all of this ought to work, but I think it's actually the most important part, as we have to make this easy to use (otherwise it won't be used). --["Users/PhilipNeustrom"]

Semantic Wiki

PhilipNeustrom — 2007-04-20 03:06:49

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 181:	Line 181:
	+ ------ + ''2007-04-20 03:06:49'' [[nbsp]] I like the simplier schema. We should talk a bit about markup and UI. [Established:=Date("1990-01-01")] versus Date Established := 1990-01-01, . If we say a type can only be one word then the latter markup would work well, I think? + + We could also opt to have this as a somewhat disjoint UI from the normal editing interface. I'm really not sure how the UI for all of this ought to work, but I think it's actually the most important part, as we have to make this easy to use (otherwise it won't be used). --["Users/PhilipNeustrom"]

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 02:51:14

Upload of image semantic_db.png.

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 02:51:14

Image semantic_db.png deleted.

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 02:49:18

point to new ERD xml

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 76:	Line 76:
- Source ERD file: [[File(semantic_sycamore.xml)]]	+ Source ERD file: [[File(metadata.xml)]]

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 02:48:34

File semantic_sycamore.xml deleted.

Semantic Wiki

Sc0ttBeardsley — 2007-04-20 02:48:13

Upload of file metadata.xml.

Semantic Wiki

Sc0ttBeardsley — 2007-03-30 16:00:22

refresh image

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 73:	Line 73:
- [[Image(semantic_db.png, right, thumbnail, "Copy the source XML into [http://ondras.praha12.net/sql/demo/ this editor] to view the schema details.")]]	+ [[Image(semantic_db.png, right, thumbnail, "Copy source XML into [http://ondras.praha12.net/sql/demo/ this editor] to view the schema details.")]]

Semantic Wiki

Sc0ttBeardsley — 2007-03-30 15:59:12

moved comments to talk

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 57:	Line 57:
- Another motivation behind this format is that on flickr people began tagging images with non-tag-like data, such as geocoordinates using a technique known as ''machine tagging''. People started using a format very similar (geo:long=123.456), and flickr ended up supporting this format and allowed querying based upon it. Check out [http://www.flickr.com/groups/api/discuss/72157594497877875/ this discussion] for more. (In our case, we'd have geo long := 123.456) The syntax of machine tagging will work for attributes but will not work for relations.	+ Another motivation behind this format is that on flickr people began tagging images with non-tag-like data, such as geocoordinates using a technique known as ''machine tagging''. People started using a format very similar (geo:long=123.456), and flickr ended up supporting this format and allowed querying based upon it. Check out [http://www.flickr.com/groups/api/discuss/72157594497877875/ this discussion] for more. (In our case, we'd have geo long := 123.456)
Line 60:	Line 60:
- - ------- - ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work (given that we always implicitly have the page we're using as a subject, and have the optional <type>). Could an example be given? For instance, the is_a::Restaurant relation could be written as Category := Restaurant, or (semantically equivalent) is_a := Restaurant. These two examples are where we have simply a <type> and a <value>, given that our general form for these things is Type Subject := Value.'' - - Well, I was thinking about allowing back references to other wiki's or pages that do not yet exist. This feature isn't necessary though for our purposes. It might make more sense to only allow forward relations where the subject is a valid wiki page and the object is possibly a wiki page on this wiki (same namespace) or on another wiki (another namespace like wikipedia, or a California wiki, etc). WikiMedia choose a different syntax for relations because the object is _always_ interpretted as a wiki page. So a wiki link is always made. Attributes, on the other hand, are not wiki pages and require some custom formatting, parsing, etc. --["Sc0ttBeardsley"] - - ''So do you think we can just opt for attributes and some sort of implicit relation? Meaning, do you think we can do the basics of what we need with just the := operator? In your examples, the only need for a relation is to set an attribute to a page. It might be easiest, from an implementation and usability perspective, to just stick with attributes?'' - - ''"just opt for attributes and some sort of implicit relation?" Yes, it would be easier to just allow forward relations (meaning the subject is always the current page).'' - - ''"just stick with attributes?" I see relations as being fundamentally different than attributes. Attributes have a specific data type, need special formatting, etc. Relations on the other hand store references to objects (not their values). In our case it could be an existing wiki page on this wiki (the default), or perhaps a wiki page on some other wiki (ie wikipedia or daviswiki.org). Either way relations are always treated the same way: add the object's namespace to the object value and you have a link to that thing. If we only had attributes how would we distinguish a value from a reference? --["Sc0ttBeardsley"]'' - - ''To answer my own question all we have to do to distinguish between a value and a reference is to look at the namespace. I now think we could get away with just an attributes table and a namespace table. See below for a new ERD. --["Sc0ttBeardsley"]''

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 06:06:38

modified table defs... example change to edit UI

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 94:	Line 94:
- ==== semantic_relation ==== - - This table stores all relationships between objects. This can include [http://en.wikipedia.org/wiki/Ontology_(computer_science) ontologies] outside of the wiki like [http://en.wikipedia.org/wiki/FOAF_%28software%29 FOAF]. For example: - {{{ - +-----+--------------+----------------+----------------+------------+----------------+--------------+ - \| id \| subject_nsid \| subject \| predicate_nsid \| predicate \| object_nsid \| object \| - +-----+--------------+----------------+----------------+------------+----------------+--------------+ - \| 654 \| 555 \| Shakey's Pizza \| 666 \| isPartOf \| 555 \| Restaurants \| - +-----+--------------+----------------+----------------+------------+----------------+--------------+ - }}} - - ==== namespace ==== - - {{{ - +-----+-----------------------------------+ - \| id \| uri \| - +-----+-----------------------------------+ - \| 555 \| http://daviswiki.org/wiki/ \| - +-----+-----------------------------------+ - \| 666 \| http://purl.org/dc/terms/isPartOf \| - +-----+-----------------------------------+ - }}}
Line 121:	Line 99:
- +-----+----------------+ - \| id \| pagename \| - +-----+----------------+ - \| 742 \| Shakey's Pizza \| - +-----+----------------+	+ +---------------+ + \| pagename \| + +---------------+ + \| Shakey's Pizza \| + +---------------+
Line 130:	Line 108:
- ==== semantic_attribute ====	+ ==== namespace ==== + + {{{ + +----+---------+---------------------------------------+ + \| id \| alias \| uri \| + +----+---------+---------------------------------------+ + \| 0 \| literal \| \| + +----+---------+---------------------------------------+ + \| 1 \| link \| http://daviswiki.org/wiki/ \| + +----+---------+---------------------------------------+ + \| 2 \| att \| http://daviswiki.org/wiki/Attributes/ \| + +----+---------+---------------------------------------+ + \| 3 \| dc \| http://purl.org/dc/terms/ \| + +----+---------+---------------------------------------+ + }}} + + ==== attribute ====
Line 134:	Line 128:
- +----+--------+--------------+---------+------------+ - \| id \| pageid \| datatypeid \| name \| value \| - +----+--------+--------------+---------+------------+ - \| 1 \| 742 \| Phone Number \| Primary \| 9161234567 \| - +----+--------+--------------+---------+------------+	+ +-----+----------------+----------------+------------+----------------+--------------+ + \| id \| pagename \| predicate_nsid \| predicate \| object_nsid \| object \| + +-----+----------------+----------------+------------+----------------+--------------+ + \| 654 \| Shakey's Pizza \| 3 \| isPartOf \| 1 \| Restaurants \| + +-----+----------------+----------------+------------+----------------+--------------+ + \| 655 \| Shakey's Pizza \| 2 \| PhoneNumber\| 0 \| 9161234567 \| + +-----+----------------+----------------+------------+----------------+--------------+
Line 141:	Line 137:
- In this case the subject is the Shakey's Pizza page, the predicate is '''Phone Number''' and the object is "9161234567". Since this data will be managed from the Shakey's Pizza page there is no need to store the full namespace or even a link to it. The name column could be removed... The reasoning is that you can "label" different type of '''Phone Numbers''' but this could just as easily be handled by creating a new data type (called say '''Secondary Phone Number'''). - - ==== semantic_datatype ==== - - This table is intended to be used for templating datatypes. Attributes can have data types that can be defined by users. For instance, take an example "phone number" data type defined as follows: - {{{ - +---------------+---------------------------------------------+---------------+ - \| name \| regex \| format \| - +---------------+---------------------------------------------+---------------+ - \| Phone Number \| ^$?([0-9]{3})$?\s*([0-9]{3})-?([0-9]{4})$ \| ($1) $2-$3 \| - +---------------+---------------------------------------------+---------------+ - }}} - - The regex is used in two ways, first to determine if the input provided by the user is valid and second to provide variables for the format variable to display the content to the user correctly. - - Using a regex will allow storing only what is necessary in the database. Take these inputs as examples (the right side is what is stored in the database). - - "(916) 123-4567" -> 9161234567 - - If you apply the regex to what is found in the database you get the following in 1,2 and 3: - - $1 = 916 - $2 = 123 - $3 = 4567 - - Then when you apply this to the format variable you will get the final result: "(916) 123-4567".	+ In this case the subject is the Shakey's Pizza page, the predicate is '''PhoneNumber''' and the object is "9161234567". Since this data will be managed from the Shakey's Pizza page there is no need to store the full namespace or even a link to it. This table can also hold relations or references to other wiki pages. If the object_nsid is 1 (the id that matches the wiki baseurl) than the object is a link and can be made into an href to the actual page.
Line 177:	Line 148:
	+ + ''Perhaps a popup window/iframe that shows a google map where when a location is clicked the window closes and the lat/lon is entered as a point like so: "Point(-143.23,235.30)".''
Line 198:	Line 171:
- * [http://www.govtrack.us/articles/20050302rdf.xpd GovTrack]	+ * [http://www.govtrack.us/articles/20050302rdf.xpd Explanation of RDF at GovTrack]

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:54:12

Image semantic_db.png deleted.

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:54:12

Upload of image semantic_db.png.

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:53:59

File semantic_sycamore.xml deleted.

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:53:59

Upload of file semantic_sycamore.xml.

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:50:53

File semantic_sycamore.xml deleted.

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:50:53

Upload of file semantic_sycamore.xml.

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:50:28

Image semantic_db.png deleted.

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:50:28

Upload of image semantic_db.png.

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:49:00

Image semantic_db.png deleted.

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:49:00

Upload of image semantic_db.png.

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:48:16

answered my own question yippee for simplicity

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 69:	Line 69:
- ''"just stick with attributes?" I see relations as being fundamentally different than attributes. Attributes have a specific data type, need special formatting, etc. Relations on the other hand store references to objects (not their values). In our case it could be an existing wiki page on this wiki (the default), or perhaps a wiki page on some other wiki (ie wikipedia or daviswiki.org). Either way relations are always treated the same way: add the object's namespace to the object value and you have a link to that thing. If we only had attributes how would we distinguish a value from a reference?''	+ + ''"just stick with attributes?" I see relations as being fundamentally different than attributes. Attributes have a specific data type, need special formatting, etc. Relations on the other hand store references to objects (not their values). In our case it could be an existing wiki page on this wiki (the default), or perhaps a wiki page on some other wiki (ie wikipedia or daviswiki.org). Either way relations are always treated the same way: add the object's namespace to the object value and you have a link to that thing. If we only had attributes how would we distinguish a value from a reference? --["Sc0ttBeardsley"]'' + + ''To answer my own question all we have to do to distinguish between a value and a reference is to look at the namespace. I now think we could get away with just an attributes table and a namespace table. See below for a new ERD. --["Sc0ttBeardsley"]''

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 05:21:41

added type functions for examples

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 31:	Line 31:
- * Longitude/Latitude (attributes): [[Location:=-12.34,23.456]] - * Neighborhood (a relation): [LocatedIn:="Downtown Davis"] <- This could be calculated once we have the long/lat and the boundaries of "Downtown Davis"	+ * Longitude/Latitude (attributes): [[Location:=Point(-12.34,23.456)]] + * Neighborhood (a relation): [LocatedIn:=Link("Downtown Davis")] <- This could be calculated once we have the long/lat and the boundaries of "Downtown Davis"
Line 34:	Line 34:
- * [HoursOpen:=M-W,0800,2200] <- These would probably need to be generated by a special UI for usability reasons - * [HoursOpen:=R-F,0800,0000] - * [HoursOpen:=S,0800,1400] - * [HappyHour:=M-F,1500,1800] - * Phone: [Phone:=(530) 753-8639] - * Email: [Email:=info@deltaofvenus.org] - * Website: [Website:=http://deltaofvenus.org] - * Est: [Established:1990] - * Menu (a relation): [Menu:="Delta of Venus/Menu"] - * Type/Category/Label (a relation or attribute it could be either): [IsA:=Restaurant]	+ * [HoursOpen:=DatetimeRange(M-W,0800,2200)] <- These would probably need to be generated by a special UI for usability reasons + * [HoursOpen:=DatetimeRange(R-F,0800,0000)] + * [HoursOpen:=DatetimeRange(S,0800,1400)] + * [HappyHour:=DatetimeRange(M-F,1500,1800)] + * Phone: [Phone:=Phone("(530) 753-8639")] + * Email: [Email:=Email("info@deltaofvenus.org")] + * Website: [Website:=URL("http://deltaofvenus.org")] + * Est: [Established:=Date("1990-01-01")] + * Menu (a relation): [Menu:=Link("Delta of Venus/Menu")] + * Type/Category/Label (a relation or attribute it could be either): [IsA:=Link("Restaurant")]

Semantic Wiki

2007-03-22 04:46:48

answered eliminating relations proposal

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 68:	Line 68:
	+ ''"just opt for attributes and some sort of implicit relation?" Yes, it would be easier to just allow forward relations (meaning the subject is always the current page).'' + ''"just stick with attributes?" I see relations as being fundamentally different than attributes. Attributes have a specific data type, need special formatting, etc. Relations on the other hand store references to objects (not their values). In our case it could be an existing wiki page on this wiki (the default), or perhaps a wiki page on some other wiki (ie wikipedia or daviswiki.org). Either way relations are always treated the same way: add the object's namespace to the object value and you have a link to that thing. If we only had attributes how would we distinguish a value from a reference?'' +

Semantic Wiki

PhilipNeustrom — 2007-03-22 02:31:19

added more to my q

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 66:	Line 66:
- ''So do you think we can just opt for attributes and some sort of implicit relation? Meaning, do you think we can do the basics of what we need with just the := operator?''	+ ''So do you think we can just opt for attributes and some sort of implicit relation? Meaning, do you think we can do the basics of what we need with just the := operator? In your examples, the only need for a relation is to set an attribute to a page. It might be easiest, from an implementation and usability perspective, to just stick with attributes?''

Semantic Wiki

Sc0ttBeardsley — 2007-03-22 00:28:37

added example for delta of venus

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 30:	Line 30:
- - ''Example needed here!''	+ * Location: + * Longitude/Latitude (attributes): [[Location:=-12.34,23.456]] + * Neighborhood (a relation): [LocatedIn:="Downtown Davis"] <- This could be calculated once we have the long/lat and the boundaries of "Downtown Davis" + * Hours: + * [HoursOpen:=M-W,0800,2200] <- These would probably need to be generated by a special UI for usability reasons + * [HoursOpen:=R-F,0800,0000] + * [HoursOpen:=S,0800,1400] + * [HappyHour:=M-F,1500,1800] + * Phone: [Phone:=(530) 753-8639] + * Email: [Email:=info@deltaofvenus.org] + * Website: [Website:=http://deltaofvenus.org] + * Est: [Established:1990] + * Menu (a relation): [Menu:="Delta of Venus/Menu"] + * Type/Category/Label (a relation or attribute it could be either): [IsA:=Restaurant]

Semantic Wiki

PhilipNeustrom — 2007-03-21 22:08:35

wrote some more, hoping for example of usage

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 16:	Line 16:
	+ + == Use cases == + + When talking about this, it's good to have an idea of what we'd like to be able to use this for. Here's some potential uses that wiki users would like (and have devised ways around, in some cases): + + * Single-element "tags" or "categories". "This page is a stub" or "This page needs a photo" or "This page is a restaurant". + * The current way of achieving this is via a normal wiki link. Because we can, for a given page, figure out what pages link to it (using {{{[[LinksHere]]}}}), we can exploit this to create "tags" or "categories," in a way. For instance, on the Davis Wiki pages which are stubs are identified by placing {{{[[Include(Stub)]]}}} on them. This includes the contents of the "Stub" page in the page we want to mark as a stub. The "Stub" page has a link to the page "Stub/Definition", and no non-stub pages link to "Stub/Definition". Thus we can produce a list of pages which are stubs by simply asking {{{[[LinksHere(Stub/Definition)]]}}}. + * Such a strategy using links can be made more geek-pallitable by choosing a set "namespace" for which to link to. We could, for instance, link to "Category/Name of the category" to ensure that nothing else linked to it. Then we would simply link to {{{["Category/Restaurant"]}}} when we wanted to mark a page as such. + * The problem with this approach is that it doesn't generalize for anything more than a single "key," and it isn't really clear what is going on -- is this a link or is this something else? We use links to express simple links between pages that are ''part of the page content'', not really to express ideas that are ''removed or abstracted from the page content.'' + * To replicate this with the current proposal, we'd simply mark a page like so: Category := Stub and Category := Photo request. We can add more information in, doing something like Stub since := 2006-02-01 and PhotoRequest since := 2006-02-01. + + * Taking details that are sitting in "formatted tables" and making them searchable. Many pages on the wikis have tables up at the top with similarly named data. These pages are usually created from something like the "Business Template." For instance, [http://daviswiki.org/Delta_of_Venus delta of venus]. The wikis tend to keep a convention for these pages' format, which means that adapting to a set convention for semantic data wouldn't be too hard for editors. In the Delta of Venus example, we have a set of attributes: Location, Hours, Phone, Email, Website, Menu (which is a link to the menu). The goal of this semantic effort is to allow these things to be queried upon, and pages to be built based on them in a straightforward way. + * To achieve this using the current Sycamore system isn't really possible. + * To replicate this using the current proposal, we could write: + + ''Example needed here!''
Line 35:	Line 51:
- ------- - ''Well, I was thinking about allowing back references to other wiki's or pages that do not yet exist. This feature isn't necessary though for our purposes. It might make more sense to only allow forward relations where the subject is a valid wiki page and the object is possibly a wiki page on this wiki (same namespace) or on another wiki (another namespace like wikipedia, or a California wiki, etc). WikiMedia choose a different syntax for relations because the object is _always_ interpretted as a wiki page. So a wiki link is always made. Attributes, on the other hand, are not wiki pages and require some custom formatting, parsing, etc. --["Sc0ttBeardsley"]''	+ + Well, I was thinking about allowing back references to other wiki's or pages that do not yet exist. This feature isn't necessary though for our purposes. It might make more sense to only allow forward relations where the subject is a valid wiki page and the object is possibly a wiki page on this wiki (same namespace) or on another wiki (another namespace like wikipedia, or a California wiki, etc). WikiMedia choose a different syntax for relations because the object is _always_ interpretted as a wiki page. So a wiki link is always made. Attributes, on the other hand, are not wiki pages and require some custom formatting, parsing, etc. --["Sc0ttBeardsley"] + + ''So do you think we can just opt for attributes and some sort of implicit relation? Meaning, do you think we can do the basics of what we need with just the := operator?''

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 15:53:43

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 36:	Line 36:
- Well, I was thinking about allowing back references to other wiki's or pages that do not yet exist. This feature isn't necessary though for our purposes. It might make more sense to only allow forward relations where the subject is a valid wiki page and the object is possibly a wiki page on this wiki (same namespace) or on another wiki (another namespace like wikipedia, or a California wiki, etc). WikiMedia choose a different syntax for relations because the object is _always_ interpretted as a wiki page. So a wiki link is always made. Attributes, on the other hand, are not wiki pages and require some custom formatting, parsing, etc. --["Sc0ttBeardsley"]	+ ''Well, I was thinking about allowing back references to other wiki's or pages that do not yet exist. This feature isn't necessary though for our purposes. It might make more sense to only allow forward relations where the subject is a valid wiki page and the object is possibly a wiki page on this wiki (same namespace) or on another wiki (another namespace like wikipedia, or a California wiki, etc). WikiMedia choose a different syntax for relations because the object is _always_ interpretted as a wiki page. So a wiki link is always made. Attributes, on the other hand, are not wiki pages and require some custom formatting, parsing, etc. --["Sc0ttBeardsley"]''

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 15:53:16

added sig

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 36:	Line 36:
- Well, I was thinking about allowing back references to other wiki's or pages that do not yet exist. This feature isn't necessary though for our purposes. It might make more sense to only allow forward relations where the subject is a valid wiki page and the object is possibly a wiki page on this wiki (same namespace) or on another wiki (another namespace like wikipedia, or a California wiki, etc). WikiMedia choose a different syntax for relations because the object is _always_ interpretted as a wiki page. So a wiki link is always made. Attributes, on the other hand, are not wiki pages and require some custom formatting, parsing, etc.	+ Well, I was thinking about allowing back references to other wiki's or pages that do not yet exist. This feature isn't necessary though for our purposes. It might make more sense to only allow forward relations where the subject is a valid wiki page and the object is possibly a wiki page on this wiki (same namespace) or on another wiki (another namespace like wikipedia, or a California wiki, etc). WikiMedia choose a different syntax for relations because the object is _always_ interpretted as a wiki page. So a wiki link is always made. Attributes, on the other hand, are not wiki pages and require some custom formatting, parsing, etc. --["Sc0ttBeardsley"]

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 15:52:10

note about possible syntax

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 35:	Line 35:
	+ ------- + Well, I was thinking about allowing back references to other wiki's or pages that do not yet exist. This feature isn't necessary though for our purposes. It might make more sense to only allow forward relations where the subject is a valid wiki page and the object is possibly a wiki page on this wiki (same namespace) or on another wiki (another namespace like wikipedia, or a California wiki, etc). WikiMedia choose a different syntax for relations because the object is _always_ interpretted as a wiki page. So a wiki link is always made. Attributes, on the other hand, are not wiki pages and require some custom formatting, parsing, etc.

Semantic Wiki

2007-03-21 07:04:19

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 34:	Line 34:
- ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work (given that we always implicitly have the page we're using as a subject, and have the optional <type>). Could an example be given? For instance, the is_a::Restaurant relation could be written as Category := Restaurant, or (semantically equivalent) is_a := Restaurant. These two examples are where we have simply a <type> and a <value>, given that our general form for these things is Type Subject := Value).''	+ ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work (given that we always implicitly have the page we're using as a subject, and have the optional <type>). Could an example be given? For instance, the is_a::Restaurant relation could be written as Category := Restaurant, or (semantically equivalent) is_a := Restaurant. These two examples are where we have simply a <type> and a <value>, given that our general form for these things is Type Subject := Value.''

Semantic Wiki

2007-03-21 07:04:07

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 34:	Line 34:
- ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work (given that we always implicitly have the page we're using as a subject, and have the optional <type>). Could an example be given? For instance, the is_a::Restaurant relation could be written as Category := Restaurant, or (semantically equivalent) is_a := Restaurant. These two examples are where we have simply a <type> and a <value>.''	+ ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work (given that we always implicitly have the page we're using as a subject, and have the optional <type>). Could an example be given? For instance, the is_a::Restaurant relation could be written as Category := Restaurant, or (semantically equivalent) is_a := Restaurant. These two examples are where we have simply a <type> and a <value>, given that our general form for these things is Type Subject := Value).''

Semantic Wiki

2007-03-21 07:03:07

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 34:	Line 34:
- ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work (given that we always implicitly have the page we're using as a subject, and have the optional <type>). Could an example be given? For instance, the is_a::Restaurant relation could be written as Category := Restaurant, or (semantically equivalent) is_a := Restaurant''	+ ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work (given that we always implicitly have the page we're using as a subject, and have the optional <type>). Could an example be given? For instance, the is_a::Restaurant relation could be written as Category := Restaurant, or (semantically equivalent) is_a := Restaurant. These two examples are where we have simply a <type> and a <value>.''

Semantic Wiki

2007-03-21 07:02:02

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 34:	Line 34:
- ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work (given that we always implicitly have the page we're using as a subject, and have the optional <type>). Could an example be given?''	+ ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work (given that we always implicitly have the page we're using as a subject, and have the optional <type>). Could an example be given? For instance, the is_a::Restaurant relation could be written as Category := Restaurant, or (semantically equivalent) is_a := Restaurant''

Semantic Wiki

2007-03-21 06:59:41

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 34:	Line 34:
- ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work. Could an example be given?''	+ ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work (given that we always implicitly have the page we're using as a subject, and have the optional <type>). Could an example be given?''

Semantic Wiki

2007-03-21 06:58:33

question about attributes and relations

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 32:	Line 32:
	+ + ------- + ''"Will work for attributes but not for relations" -- This is what I thought at first, too, but I can't seem to think of a case where it wouldn't work. Could an example be given?''

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 06:32:38

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 178:	Line 178:
	+ ------ + ''2007-03-20 23:32:38'' [[nbsp]] To recap relation vs attribute: relations connect two objects and attributes connect an object to a literal (like a date/number/string). There is a good discussion about this on [http://meta.wikimedia.org/wiki/Semantic_MediaWiki/Blueprint MediaWiki's blueprint page]. --["Sc0ttBeardsley"]

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 06:30:19

typo

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 21:	Line 21:
- * {{{is_a::Restaurant}} (general form is predicate::object and the subject is extracted automatically)	+ * {{{is_a::Restaurant}}} (general form is predicate::object and the subject is extracted automatically)

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 06:29:18

example relation

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 20:	Line 20:
- * A relation: {{{[[Relation(wiki:CURRENTPAGE,wiki:is_a,wiki:restaurant)]]}}}	+ * A relation: {{{[[Relation(CURRENTPAGE,is_a,Restaurant)]]}}} + * {{{is_a::Restaurant}} (general form is predicate::object and the subject is extracted automatically)
Line 30:	Line 31:
- ''See the talk page''	+ ''see also: [http://meta.wikimedia.org/wiki/Semantic_MediaWiki/Blueprint MediaWiki's Blueprint page]''

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 06:17:38

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 17:	Line 17:
- A possible format for this plugin is:	+ == Possible syntax == + + Possible formats for relations:
Line 19:	Line 21:
- * An Attribute: {{{[[Attribute("Phone Number","(916) 123-4567")]]}}}
Line 21:	Line 22:
- Or, how about: - * An attribute: Category := Restaurant - * An attribute: PhoneNumber := (916) 123-4567 - * An attribute: Hours open := 9AM-5PM - - (general form is Type Subject := Value)	+ Possible formats for attributes: + * {{{[[Attribute("Phone Number","(916) 123-4567")]]}}} + * {{{PhoneNumber := (916) 123-4567}}} (general form is Type Subject := Value)
Line 30:	Line 28:
- Another motivation behind this format is that on flickr people began tagging images with non-tag-like data, such as geocoordinates. People started using a format very similar (geo:long=123.456), and flickr ended up supporting this format and allowed querying based upon it. Check out [http://www.flickr.com/groups/api/discuss/72157594497877875/ this discussion] for more. (In our case, we'd have geo long := 123.456)	+ Another motivation behind this format is that on flickr people began tagging images with non-tag-like data, such as geocoordinates using a technique known as ''machine tagging''. People started using a format very similar (geo:long=123.456), and flickr ended up supporting this format and allowed querying based upon it. Check out [http://www.flickr.com/groups/api/discuss/72157594497877875/ this discussion] for more. (In our case, we'd have geo long := 123.456) The syntax of machine tagging will work for attributes but will not work for relations. + + ''See the talk page''
Line 54:	Line 54:
- This table stores all relationships between objects. This can include [http://en.wikipedia.org/wiki/Ontology_(computer_science) ontologies] outside of the wiki like [http://en.wikipedia.org/wiki/FOAF_%28software%29 FOAF]. Example coming soon.	+ This table stores all relationships between objects. This can include [http://en.wikipedia.org/wiki/Ontology_(computer_science) ontologies] outside of the wiki like [http://en.wikipedia.org/wiki/FOAF_%28software%29 FOAF]. For example: + {{{ + +-----+--------------+----------------+----------------+------------+----------------+--------------+ + \| id \| subject_nsid \| subject \| predicate_nsid \| predicate \| object_nsid \| object \| + +-----+--------------+----------------+----------------+------------+----------------+--------------+ + \| 654 \| 555 \| Shakey's Pizza \| 666 \| isPartOf \| 555 \| Restaurants \| + +-----+--------------+----------------+----------------+------------+----------------+--------------+ + }}}

Semantic Wiki

2007-03-21 05:06:21

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 21:	Line 21:
- How about just attributes, without relations?	+ Or, how about:

Semantic Wiki

2007-03-21 05:05:10

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 30:	Line 30:
- With this format, we cannot express 'relation' in the same way, because we can't really specify a 'predicate.' We can, however, specify a type, which can act in the same way a predicate could. (When would we need a non-trivial predicate?..) Another motivation behind this format is that on flickr people began tagging images with non-tag-like data, such as geocoordinates. People started using a format very similar, and flickr ended up supporting this format and allowed querying based upon it. Check out [http://www.flickr.com/groups/api/discuss/72157594497877875/ this discussion] for more.	+ Another motivation behind this format is that on flickr people began tagging images with non-tag-like data, such as geocoordinates. People started using a format very similar (geo:long=123.456), and flickr ended up supporting this format and allowed querying based upon it. Check out [http://www.flickr.com/groups/api/discuss/72157594497877875/ this discussion] for more. (In our case, we'd have geo long := 123.456)

Semantic Wiki

2007-03-21 05:00:02

another format

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 30:	Line 30:
- When would we need a non-trivial predicate?	+ With this format, we cannot express 'relation' in the same way, because we can't really specify a 'predicate.' We can, however, specify a type, which can act in the same way a predicate could. (When would we need a non-trivial predicate?..) Another motivation behind this format is that on flickr people began tagging images with non-tag-like data, such as geocoordinates. People started using a format very similar, and flickr ended up supporting this format and allowed querying based upon it. Check out [http://www.flickr.com/groups/api/discuss/72157594497877875/ this discussion] for more.

Semantic Wiki

2007-03-21 04:54:58

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 20:	Line 20:
	+ + How about just attributes, without relations? + * An attribute: Category := Restaurant + * An attribute: PhoneNumber := (916) 123-4567 + * An attribute: Hours open := 9AM-5PM + + (general form is Type Subject := Value) + + With this form, we can explain the idea to newcomers as a way of "tagging the page with a value," in a sense. + + When would we need a non-trivial predicate?

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 04:20:00

typo

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 19:	Line 19:
- * An Attribute: {{{[[Attribute("Phone Number","(916) 123-4567)]]}}}	+ * An Attribute: {{{[[Attribute("Phone Number","(916) 123-4567")]]}}}

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 04:19:13

comment change

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 158:	Line 158:
- ''2007-03-20 21:18:20'' [[nbsp]] Yes, generally a page and another object... the page can either be the subject or the object... I don't think it'll work if it's one way. The database structure would allow storing relationships between two non-page objects but that's not all that interesting for our purposes. --["Sc0ttBeardsley"]	+ ''2007-03-20 21:18:20'' [[nbsp]] Yes, generally a page and another object... the page can either be referenced in the subject or the object... The database structure would allow storing relationships between two non-page objects but that's not all that interesting for our purposes. --["Sc0ttBeardsley"]

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 04:18:20

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 157:	Line 157:
	+ ------ + ''2007-03-20 21:18:20'' [[nbsp]] Yes, generally a page and another object... the page can either be the subject or the object... I don't think it'll work if it's one way. The database structure would allow storing relationships between two non-page objects but that's not all that interesting for our purposes. --["Sc0ttBeardsley"]

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 04:15:33

added possible plugin formats

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 17:	Line 17:
	+ A possible format for this plugin is: + * A relation: {{{[[Relation(wiki:CURRENTPAGE,wiki:is_a,wiki:restaurant)]]}}} + * An Attribute: {{{[[Attribute("Phone Number","(916) 123-4567)]]}}} +
Line 19:	Line 23:
- * John's Phone Number is 530-123-4567	+ * John's Phone Number is (916) 123-4567

Semantic Wiki

2007-03-21 04:14:27

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 151:	Line 151:
	+ ------ + ''2007-03-20 21:14:27'' [[nbsp]] So what you had in mind is that the relationship is always between a page and another object? --75.31.44.27

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 04:09:41

clarified my comment

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 150:	Line 150:
- ''2007-03-20 21:05:08'' [[nbsp]] I think the attribute table needs to be changed. the predicate should be able to be one of the standard predicates in DC, FOAF, etc. I'd like it also to be a custom datatype also. The semantic_relation table is for showing relations between two real world things. One of those things is represented as a page in the wiki the other can be another page in the wiki or some other real world thing. For example "Shakey's Pizza" "Is A" "Restaurant". --["Sc0ttBeardsley"]	+ ''2007-03-20 21:05:08'' [[nbsp]] I think the attribute table needs to be changed. the predicate should be able to be one of the standard predicates in DC, FOAF, etc. I'd like it also to be a custom datatype also. The semantic_relation table is for showing relations between two real world things. One of those things is represented as a page in the wiki the other can be another page in the wiki or some other real world thing. For example "Shakey's Pizza" "Is A" "Restaurant" the "Shakey's Pizza" has the local wiki's namespace so it represents the page in the wiki. --["Sc0ttBeardsley"]

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 04:08:09

relation table still needs an example

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 39:	Line 39:
- This table stores all relationships between objects. This can include [http://en.wikipedia.org/wiki/Ontology_(computer_science) ontologies] outside of the wiki like [http://en.wikipedia.org/wiki/FOAF_%28software%29 FOAF]. Here is an example row:	+ This table stores all relationships between objects. This can include [http://en.wikipedia.org/wiki/Ontology_(computer_science) ontologies] outside of the wiki like [http://en.wikipedia.org/wiki/FOAF_%28software%29 FOAF]. Example coming soon. + + ==== namespace ====

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 04:06:16

fixed table name

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 37:	Line 37:
- ==== namespace ====	+ ==== semantic_relation ====
Line 49:	Line 49:
- \| 777 \| http://daviswiki.org/wiki/ \| - +-----+-----------------------------------+
Line 52:	Line 50:
- - ''This example table is the namespace table?''

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 04:05:08

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 151:	Line 151:
	+ ------ + ''2007-03-20 21:05:08'' [[nbsp]] I think the attribute table needs to be changed. the predicate should be able to be one of the standard predicates in DC, FOAF, etc. I'd like it also to be a custom datatype also. The semantic_relation table is for showing relations between two real world things. One of those things is represented as a page in the wiki the other can be another page in the wiki or some other real world thing. For example "Shakey's Pizza" "Is A" "Restaurant". --["Sc0ttBeardsley"]

Semantic Wiki

2007-03-21 04:03:56

example table is the namespace table

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 37:	Line 37:
- ==== semantic_relation ====	+ ==== namespace ====
Line 52:	Line 52:
	+ + ''This example table is the namespace table?''

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 03:53:30

semantic_relation table example

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 36:	Line 36:
	+ + ==== semantic_relation ==== + + This table stores all relationships between objects. This can include [http://en.wikipedia.org/wiki/Ontology_(computer_science) ontologies] outside of the wiki like [http://en.wikipedia.org/wiki/FOAF_%28software%29 FOAF]. Here is an example row: + + {{{ + +-----+-----------------------------------+ + \| id \| uri \| + +-----+-----------------------------------+ + \| 555 \| http://daviswiki.org/wiki/ \| + +-----+-----------------------------------+ + \| 666 \| http://purl.org/dc/terms/isPartOf \| + +-----+-----------------------------------+ + \| 777 \| http://daviswiki.org/wiki/ \| + +-----+-----------------------------------+ + }}}

Semantic Wiki

2007-03-21 03:02:43

tad more in an example

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 1:	Line 1:
- = What is a Semantic Wiki =	+ = What is a Semantic Wiki? =
Line 6:	Line 6:
	+ + Another example of semantic data is the "address" of a place. We can make a wiki page for a place, like Sam's Pizza, but then we'd like to give it an address. We can simply write the address on the page, or we can use the {{{[[address]]}}} macro to identify the address of the page in a way that's more meaningful to Sycamore. Because of this, the address of the page gets plotted on a map. The idea behind the semantic effort is to allow us to express other ideas, like "address" or "category" in a way that is understandable to computers, while being painless for people.

Semantic Wiki

2007-03-21 03:00:11

Comment added.

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 129:	Line 129:
	+ ------ + ''2007-03-20 20:00:11'' [[nbsp]] The semantic_attribute table is said to "[define] attributes for objects stored in the wiki", and has subject, predicate, and object. But so does the semantic_relation table? What's the purpose of that table? --75.31.44.27

Semantic Wiki

Sc0ttBeardsley — 2007-03-21 02:15:03

added example rows and some table descriptions

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 5:	Line 5:
- ==== A simple example ====
Line 7:	Line 6:
-
Line 37:	Line 35:
	+ ==== page ==== + + This is a table with all pages in the wiki. Here is an example row: + {{{ + +-----+----------------+ + \| id \| pagename \| + +-----+----------------+ + \| 742 \| Shakey's Pizza \| + +-----+----------------+ + }}} + + This can easily be changed to use the current Sycamore standard which is to use the pagename as the unique id. + + ==== semantic_attribute ==== + + This table defines attributes for objects stored in the wiki. Every page is an object. This table follows the subject-predicate-object rule because the page id (or pagename) is the subject. Here is an example phone number attribute for the '''Shakey's Pizza''' page. + {{{ + +----+--------+--------------+---------+------------+ + \| id \| pageid \| datatypeid \| name \| value \| + +----+--------+--------------+---------+------------+ + \| 1 \| 742 \| Phone Number \| Primary \| 9161234567 \| + +----+--------+--------------+---------+------------+ + }}} + + In this case the subject is the Shakey's Pizza page, the predicate is '''Phone Number''' and the object is "9161234567". Since this data will be managed from the Shakey's Pizza page there is no need to store the full namespace or even a link to it. The name column could be removed... The reasoning is that you can "label" different type of '''Phone Numbers''' but this could just as easily be handled by creating a new data type (called say '''Secondary Phone Number'''). +
Line 39:	Line 63:
- This table is intended to be used for templating datatypes. Attributes can have data types that can be defined by users. For instance, take a "phone number" data type. The regex might be something like: - - "^$?([0-9]{3})$?\s*([0-9]{3})-?([0-9]{4})$" - - And the format might be: - - "($1) $2-$3"	+ This table is intended to be used for templating datatypes. Attributes can have data types that can be defined by users. For instance, take an example "phone number" data type defined as follows: + {{{ + +---------------+---------------------------------------------+---------------+ + \| name \| regex \| format \| + +---------------+---------------------------------------------+---------------+ + \| Phone Number \| ^$?([0-9]{3})$?\s*([0-9]{3})-?([0-9]{4})$ \| ($1) $2-$3 \| + +---------------+---------------------------------------------+---------------+ + }}}

Semantic Wiki

FarMcKon — 2007-03-21 01:45:55

Cool. I Added a simple example. I'm not sure if it's even useful at all....

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 3:	Line 3:
- Semantic is to give meaning to something. In this case it means to give meaning to data managed via a user-maintained website or wiki. Semantic data is also known as metadata. Both mean information about information. Semantic data can be expressed in a set of exactly three pieces of data. Together these pieces are called statements.	+ The word [http://en.wikipedia.org/wiki/Semantics Semantic] is related to the meaning carried by an any communication in words, code, drawing, anything. The idea of Semantic Wiki (or semantic web) is to write or create information in a way that make it easy to process and use by software agents. Many people use the term Semantic data and metadata interchangeably. In the case of Semantic Wiki it means to giving richer meaning to data managed via a user-maintained website or wiki. Both mean information about information. Semantic data can be expressed in a set of exactly three pieces of data. Together these pieces are called statements. + + ==== A simple example ==== + A simple example of semantic data is HTML's 'bold' tag. A word, paragraph, or sentence can be put between an opening <b> and a closing </b>. In most cases this just means the text in the middle is drawn in italics when it's viewed. But some software will use the tag to otherwise mark the information as bold. For example, screen readers for the blind can change tone or inflection for <b> tags. In short, it's not directly drawn to the screen, but the technology in the middle can help make that un-drawn information useful. +

Semantic Wiki

2007-03-21 01:03:18

Differences for Semantic Wiki

Deletions are marked with - .	Additions are marked with +.
Line 99:	Line 99:
- ''2007-03-20 17:56:15'' [[nbsp]] Why is there no relationship between the semantic_attribute table and the semantic_relation table? After we create a datatype and place it into the semantic_attribute table, doesnt' that datatype get associated with the predicate of the semantic_relation table? I can define a phone number's form and say that it is a phone number, but then when I encounter another phone number I'd like to use the same row from semantic_attribute, as the predicate is the same. --75.31.44.27	+ ''2007-03-20 17:56:15'' [[nbsp]] Why is there no relationship between the semantic_attribute table and the semantic_relation table? After we create a datatype and place it into the semantic_attribute table, doesn't that datatype get associated with the predicate of the semantic_relation table? I can define a phone number's form and say that it is a phone number, but then when I encounter another phone number I'd like to use the same row from semantic_attribute, as the predicate is the same. (Though, I notice the semantic_attribute is tied to a specific page, too. I suppose I need more clarification as to its purpose. I know it's for identification of types, but I'm not sure how it's fitting in.) --75.31.44.27