OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-courtfiling message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [legalxml-courtfiling] JXDDS Person Object


Of the diagram:
The diagram is not precise enough for me to say I have no issue with it.

But, I think, it is very close to a data-model that I would support.
I would like to speak more with the authors... will they be at Boston?


John Messing writes:
>>I would like to see developed a Party object and a non-Party object. <<

Surely, these two objects are two flavors of the SAME thing.  I sense that
the only difference in your proposed objects is that you see 'party' as
being related to a case/filing and non-party as not.  If that is the only
difference, then, we should be able to define some kind of 'Named-thing',
from which your 'party' or 'non-party' would both inherit their common
characteristics.

I think that's all the diagram is trying to express. along with a suggestion
that the 'thing' be called 'actor'.  You can have 'party' and 'non-party'..
but they are both sub-types of 'actor'. eh?


On the semantic issue of 'Actor' vs 'Party' vs. 'Participant'.

We need to have a generic term that represents a 'Named-thing' that has a
'name' and can behave as a person, business, or property.  This
'named-thing' needs a title that is independant of its possible
case/filing/document contexts. 

As Allen Jenson noted, this is really a technical term/definition issue...
and it should not effect our functional terms.

I think 'actor' is a suitable title for our generic 'Named-thing'.

As I read the diagram, it does not say that 'actor' is the specific XML
tag-name of a litigant or judge or attorney or witness... 

The diagram only says that 'whatever you want to call it', if your object
has a 'name' and behaves 'like a Named-thing' then it should conform to the
defined data-format of 'person', 'organization', or 'property', which are
all sub-types of 'actor'.


Honestly, it makes perfect sense to me.. and I think that it is a step in
the right direction.
- Shane



Technical comment concerning given diagram:

i) Correct me if I am wrong: I think 'SuperObject', 'Actor', 'Person',
'Organization', and 'Property' are all intended to be "abstract objects" -
they only define data structure that other objects can inherit (borrow,
mimic, adhere to).  Whereas 'citizen', 'official', and 'subject' are
*examples* of 'actor' objects that *could* be invented and implemented in
the various LegalXML API sub-groups. 

ii) The inheritance arrows between 'actor' and 'person / organization /
property' seem incorrect (the inheritence arrows point BOTH ways.).  Correct
me if I am wrong: I think the designers intend for 'person', 'organization',
and 'property' to inherit from 'actor'. (arrows would be pointed only
towards 'actor')



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC