Fwd: Arcs

oops... (this is take #3, actually.... brilliant start to the day! ;)

Begin forwarded message:

> From: "Andrew S. Townley" <[email protected]>
> Date: 21 October 2010 8:45:13 AM GMT+01:00
> To: Xuân Baldauf <xuan--2007--topicmapmail--infoloom.com-IBzAk7fUI6RAfugRpC6u6w@public.gmane.org>
> Subject: Re: [topicmapmail] Arcs
> 
> 
> On 21 Oct 2010, at 1:41 AM, Xuân Baldauf wrote:
> 
>> 
>> Benjamin Bock has proposed arcs in Prague 2009 and I have used arcs without problems in a project. My definition of "arc" is as follows:
>> An arc denotes an association perspective. An association perspective with respect to a particular association is a perspective as seen 
>> 	• by a player of such an association
>> 	• though this association
>> 	• towards another player of this association.
>> Arcs are independent of the particular association, hence they are independent of the particular players of an association. Hence, each particular arc is defined by
>> 	• ("from") the type of the role of the local player
>> 	• ("type") the type of the association
>> 	• ("to") the type of the role of the remote player
>> (This definition may be incomplete, as more-than-2-ary-associations may not be well-covered, but I haven't needed arcs for these types of associations so far.)
>> 
>> My CTM template for arcs is as follows:
>> %prefix arc http://psi.baldauf.org/arc/
>> 
>> def arc($type,$from,$to,$reifier)
>>    arc:arc(arc:from: $from,arc:type: $type,arc:to: $to) ~ $reifier
>> end
>> and arcs can be used as
>> arc:arc(arc:from: newcombumber:introducer, arc:type: newcombumber:introduced-to-tm, arc:to: newcombumber:introducee) ~ [
>>  - "introduced Topic Maps to"
>> ]
>> 
> ...
>> So, what does the community think about arcs? I think it is time to create some community modeling standards, and something like arcs should be parts of these standards.
> 
> Your (and Benjamin's, I guess although I didn't read his paper) definition of an arc corresponds exactly to my understanding of a TMRM Proxy Property as described in [1] as part of Section 4 "Subject Properties and Maps"
> 
> The usefulness of "arcs" that you describe is another one of the key reasons I carry on so much about using the TMRM vs. the TMDM and why I based my implementation on TMRM.
> 
> All an arc really represents is a particular type of property, so I'd say extensive use of arcs in any map would complicate identifying the intended proxy properties in any map, and thus actually increase interoperability difficulties with other semantic representations rather than ease them.
> 
> Our approach to applying the TMRM has been to define (semi-formally) the relationship between proxy properties, occurrences and associations so that we can both consume and create TMDM serializations.  As you allude in your description, the beauty of an "arc" or proxy property is that you only have one type of entity to deal with, but it does mean that you have to provide conditional handling of whether the value references a literal or another proxy (although in a TMDM world, you'd only ever be dealing with topics).
> 
> However, this feature also allows you to dynamically evolve your ontology as the complexity of what you need to do also evolves.  Back to a recent discussion about Dublin Core, today your author identifier is a literal string, in a month, you actually want to do something useful with authors, so you need to migrate them to proxies.  Not a big deal, actually, if you're using TMRM as you don't even actually need to change the label.  With TMDM implementations, you must change the underlying structure and the constructs used to represent the arc itself (from an occurrence to an association).
> 
> I fully understand that you can manage this kind of transition in both models, but my point is that what you're really signifying is an "arc" type relationship between two entities--one that signifies a labeled property of a topic whose value is another topic--is handy to have.  That this doesn't easily fit into the TMDM model because you can't have occurrences whose value points to another topic, and that it's a fairly useful thing to do might mean that a closer relationship between the TMRM and TMDM might be a very good thing.  It also has the benefit of increased interoperability with other standards.
> 
> Cheers,
> 
> ast
> 
> 1 - http://www.isotopicmaps.org/TMRM/TMRM-7.0/tmrm7.pdf
> --
> Andrew S. Townley <[email protected]>
> http://atownley.org
> 

--
Andrew S. Townley <[email protected]>
http://atownley.org