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?
-Yaron
On 9/11/07, S Page <[EMAIL PROTECTED]> wrote:
>
> 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 [EMAIL PROTECTED]" 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 [1], 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,
> http://ontoworld.org/wiki/N-ary_relations and
> http://ontoworld.org/wiki/Berlin
>
> 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
> works currently.
>
> 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.
>
> [1]
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=92475E44-19E0-4D07-A626-8C60A697216E%40rdfined.dk&forum_name=semediawiki-user
>
> --
> =S Page
>
> > 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 PROTECTED] [mailto:
> [EMAIL PROTECTED] *On
> > Behalf Of *Dan Thomas
> > > *Sent:* Saturday, September 08, 2007 7:24 AM
> > > *To:* Semediawiki-devel@lists.sourceforge.net
> > > *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.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
