Minutes / IRC log. SIMILE Telecon 30 May 2003

We discussed three topics on the call, all in review of Jason's current 
history system design document:

1. How to extend data model (best practice):
     By Subclass?
     By Subproperty?
     Both?

   Outcome: Need further discussion and clarification on list.

2. Capability/Utility of queries incorporating negative assertions

   Outcome:
	JK: Useful/Required for certain history system query use cases.
	AS: There are alternative ways of modelling that don't require it.
	JK: Still unclear how to implement?

3. Producing Metadata Disseminations from Metadata in the History System Store

   Summary:
	JK: History System gathers metadata about state in past situations,
	    that can be queried.  Makes no assumption about what subgraphs
	    could/should be disseminated for particular URIs in the data model.
	AS: Should be able to http:get a name and receive metadata about it
	MB: What's missing is the mapping: what's the implied query that
	    determines the subgraph to return for the name.  Also (future)
	    could return disseminations that are not metadata, but content.

   Outcome:
	JK to schedule additional telecon.  Timing logistics TBD on list.
	Bass to supply phone bridge.

FIN

[12:01] <mickBass> Attending:
[12:01] <mickBass> Kevin Smathers
[12:01] <mickBass> Mark Butler
[12:01] <mickBass> Jason Kinner
[12:02] <mickBass> Andy Seaborne
[12:03] <mickBass> Scribe: Kevin Smathers
[12:03] <mickBass> Backup Scribe: Mick Bass
[12:06] <kevins2> jk: design doc feedback request.  new update available, 
includes marks comments and new diagrams
[12:06] <kevins2> jk, dated may 28
[12:06] <kevins2> jk, will accept comments via email.
[12:07] <mickBass> http://web.mit.edu/simile/www/resources/history-
harmony/history-design.pdf
[12:08] * marbut has joined #simile


===
On extension of Data Model using Subclass and/or Subproperty
a.k.a. "Do/Should Subproperties vary meaning based on context?"
===

[12:09] <kevins2> jk, clarify date and event
[12:09] <kevins2> jk, defined explicitly in schema
[12:10] <kevins2> jk, i like subEventOf, but there is no use case for that in 
current simile
[12:11] <kevins2> mb, need refinements of date to refine example, or use 
subproperties from Harmony as an example
[12:12] <kevins2> mb, might be subclassed from dc:date, but dc:date is too 
general to use directly.
[12:13] <kevins2> jk, i have seen date used as property directly.  no idea 
what they were talking about in that case, has to be inferred.
[12:13] <kevins2> mb, semantic meaning of date changes according to context; 
ie where it is referenced.
[12:14] <kevins2> jk, classes and properties with the same name?
[12:14] <kevins2> jk, created event, and created property.
[12:15] <kevins2> jk, need to be equated.
[12:15] <kevins2> jk, meaning is the same.
[12:17] <kevins2> jk, creates is subproperty of hasResult, destroys is 
subProperty of hasPatient, subproperty of involves
[12:17] <kevins2> range is an actuality
[12:18] <kevins2> discuss figure 5.
[12:18] <kevins2> jk, will it be clear how to extend schema 
[12:19] <kevins2> jk, event and property are defined by Harmony -- given that, 
how to extend schema to other possible actions and events?
[12:19] <kevins2> jk, event and action are themselves too generic.
[12:19] <kevins2> jk, need new classes that are subclasses of event and action.
[12:20] <kevins2> jk, but these aren't acceptable to community.  need to move 
in the direction of specific classes with specific properties.
[12:20] <kevins2> jk, eg.: event modify should have subproperties that 
identify the record modified.
[12:21] <kevins2> jk, currently only using basic Harmony/ABC in the diagrams 
(eg: Fig 6)
[12:22] <kevins2> jk, two issues -- can't use generic property that changes 
its semantics in the context of different classes.
[12:24] <kevins2> jk, secondly -- extending the schema by creating new 
subproperties for their implementation e.g transforms class representing 
action and event, + subproperties of hasresult that 
represent 'yieldsTransformation'.  Can't cleanly extend via classes, nor from 
properties.  Easier to use type of class as part of the query.
[12:24] <kevins2> jk, subproperty is harder to understand 
[12:25] <kevins2> jk, subclasses of actions and events are needed, but need 
subproperties as well to really help.
[12:28] <kevins2> bass, suppose i create a subclass of modified that is 
transforms...
[12:28] <kevins2> range is ...?
bass: what's wrong with using hasResult with *domain* = transforms, without 
defining a subproperty?  (yes, I did say range on the call...)
[12:29] <kevins2> jk, does hasResult sufficiently model the semantics of 
modified in the sense of transform?
[12:30] <kevins2> bass, is it broken, or is it a user concern that the users 
won't model it correctly?
[12:33] <kevins2> mb, users need guidance.
[12:34] <kevins2> mb, key problem is modelling, and there is no set of known 
good practices.
[12:34] <kevins2> mb, digraphs are an unknown.
[12:34] <kevins2> jk, this model has some responsibility in detemining best 
practices.

===
On RDF/RDQL Query Capabilities wrt negative assertions?
===


[12:36] <kevins2> jk, andy -- about rdql -- is there a way to make a negative 
assertion in the graph pattern?
[12:36] <kevins2> as, no closed world assumptions.
[12:37] <kevins2> jk, most recent version of the object; can't ask what is the 
object that doesn't have a successor.
[12:37] <kevins2> as, other ways to accomplish that -- a closed list that 
lists objects in creation order for example.
[12:39] <kevins2> jk, subqueries for example.
[12:40] <kevins2> as, does a subgraph pattern not exist is really what you are 
looking for
[12:43] <kevins2> jk, bass: discuss query results as linked list.
[12:43] <kevins2> as, there are more ways to examine a graph than by query.
[12:44] <kevins2> as, fine grained tests include exact tests for a 
relationship.
[12:44] <kevins2> jk, for remote clients that won't work.
[12:44] <kevins2> jk, need to pose useful queries for haystack.

===
On producing Disseminations from Metadata in History System Store
===

[12:46] <kevins2> as, abstraction -- url per resource
[12:46] <kevins2> jk, unclear what URL producing metadata dissemination should 
be linked to.  history system can't predict 
[12:47] <kevins2> as, community, collection, ...
[12:47] <kevins2> jk, can't guarantee that handle resolves, or resolves to 
metadata.
[12:51] <kevins2> discussion re handles
[12:52] <kevins2> as, history store can't be asked what it knows about object 
x.  
[12:53] <kevins2> bass, could be an implied query that returns data from the 
handles.
[12:55] <kevins2> as, need to be able to ask history system what it knows 
about a particular object -- full data of the historical object.
[12:56] <kevins2> bass, issue is what data would be needed from an HTTP get.  
One case is what metadata we want, the other is that the history system may 
need to roll back.
[12:56] <kevins2> jk, right now history system has no access to that 
information.
[12:57] <kevins2> jk, can't produce disseminations based on these handles.

Received on Friday, 30 May 2003 13:59:10 UTC