Thanks, S, for finally detailing what n-ary relations will look like in SMW 1.0 - this was an issue of great curiosity to at least a few of us on the mailing list.
That said (and I apologize if I'm now hijacking this thread) - are you sure that this is the best way to implement them? The other way, instead of composite types, is to keep using simple types, and define the relationship between a set of n-ary relations using semantic markup; you could call it the composite-property approach. It's the difference between saying "San Francisco has a property which is of type number+year", and "San Francisco has a property of type number, and a property of type year, which are joined together".
I can think of a few arguments in favor of the latter approach:
- most importantly, the "composite-type" approach doesn't allow you to define the specific property of each field. If a new property is composed of, say, three integers and two strings, how can anyone know what each of these fields actually is? And what will appear in the exported RDF for each value?
- also, the latter allows for setting the display of the data at the same time that the values are set - with the former approach, it seems like you'd always have to manually pipe on the text display, as you did in your example.
- joined in with this, you can call the values in any order, instead of being required to always call them in the order they appear in the property definition.
- speaking out of somewhat selfish reasons, the composite-type approach will (I think) require a good amount of extra work for the Semantic Forms extension. SF will have to extract all the basic types out of each property to figure out what the inputs should look like. Also, the special forms to create properties and create templates will have to be overhauled, in a way that I don't think would be true if it were done through composite properties. (I could be wrong about this - maybe it would be easier than it seems.)
Can you explain the reasoning that went into this decision? Is it that composite types allow for more structure in doing searches and the like?
Jeff Thompson wrote:
> RDF has two ways to handle this. I don't think SMW supports either in a direct way.
> 1. Blank nodes. Instead of a property having a value of type integer, it has a value
> of a composite type that has an integer, date, etc. Since it is a "blank node" you
> don't need to create a unique URI for it (or its own page in SMW). "Blank nodes" are
> used in RDF all the time, for example as the nodes in a list, or to mention "the person
> that has email address firstname.lastname@example.org" without needing to give that object its own
> unique identifier, and also to make "composite types" like the date/integer you mention.
> 2. Reification. If your statement is "San Francisco has population 739426", then you make
> a separate object of type Statement where the subject is "San Francisco", the predicate is
> "has population" and the object is "739426". Then you can extend this to say "this statement"
> is true on the date 2005. (Since the Statement object is usually a blank node, it kind of
> amounts to the same as option 1.)
> The closest thing I see in in SWM is Type:Geographic coordinate which is basically a blank node
> with a latitude and longitude property. Are there any plans in SMW to support blank nodes, custom
> composite types, or reification?
I just described SMW 1.0prealpha-3's support for N-ary properties in
response to [Semediawiki-user] Typed links vs. OWL-relations , the
same applies here.
Property:Population_(on_date) would have [[Has type::Integer; Date]]
The Berlin article would say [[Population (on date)::3405000; 2006-11|
3,405,000 as of November 2006]]
You can omit values, so you could have lots of optional values for a
property as Harold Solbrig suggested. Try it out,
Maybe SMW's N-ary feature is your "blank node", I'm not sure of the
nomenclature. As I understand it "reification" is more for talking
about the statement (who made it, when they made it, where it appeared)
rather than facts within the statement (the date range over which it's
true, additional facts qualifying it).
Your idea to make an underlying compound datatype for all properties
with the same set of values is nice; you could then say
Property:Population [[Has type::Dated_integer]]. But that's not how SMW
BTW, although Type:Geographic_coordinate seems like a compound type, it
still has to fit all its information into the generic smw_attributes
database table -- new columns don't magically appear for two float values.
> Harold Solbrig wrote:
> > Dan,
> > Why just integers? It would seem like it would be useful to be able to add provenance (who, when, where…)
> information to any property – not just integers. President:=Johnson - 1965 or hasChild :: Sarah – 2003
> definedIn:=http://w3.org/sample/prelimVersion 2007-08-07
> > Harold Solbrig
> > ------------------------------------------------------------------------
> > *From:* email@example.com [mailto:firstname.lastname@example.org] *On
> Behalf Of *Dan Thomas
> > *Sent:* Saturday, September 08, 2007 7:24 AM
> > *To:* Semediawikiemail@example.com
> > *Subject:* [SMW-devel] dated integer type
> > I have run across a concept called 'dated integer' that I propose become a native SMW data type. As the name
> implies, one can associate a number with a year:
> > population:=9,999 - 2005 or
> > homeruns:=756 - 2007-08-07.
> > Do others think this would be useful?
> > --
> > --
> > Dan Thomas
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
Semediawiki-devel mailing list