Re: new core data model posted

A review of time specifications for potential re-use would be great, IMHO.

---
Raj
The OGC: Making location count...
http://www.opengeospatial.org/contact


On Oct 25, at 5:37 PM, Yarik Sheptykin wrote:

> Hi Raj!
> 
> I see your point. It seems like a findamental modeling problem in xml: attributes or elements? I personally prefer elements because they leave more freedom for the leter changes and allow to simplify xsd in a way. Let's say you want to make sure that "created" appears only once. You would accomplish this with trivial effort if you have "created" as an element (<time><created /></time>). I have no idea how one can do it if "created" is a marker attribute (<time type="created" />), but I am not a big xpert in xsd-crafting. I have had a look on how guys have solved this in gml spec and they also seem to genarally prefer elements in favour of attrs.
> But I have to admit I wrote my solution before I had a chance to closely study the model. I guess I missed the conversation on the purpose of the time field in the POIType. As far as I can read uml it inherits created, modified and deleted from the basetype already. And then again you add a timestamp which is termtype <- basetype with a bunch of temporally unrelated stuff (as for me) like author and licence for ex. Do I miss something?
> Additionally, I am curious if it makes sence to check the existing models of time and just reuse them within the Poi spec. Just like you did with the spatial types. Shooting randomly: gml spec has a paragraph on "temporal information and dynamic features". Might be a place to check. Do you think it make sence? I could check this and other resourses then.
> 
> Greets,
> Yarik 
> 
> 
> Raj Singh <rsingh@opengeospatial.org> wrote:
> 
>> Thank you very much for jumping in. Sometimes it feels like only a few people care about this work. 
>> 
>> What you show does make a lot of sense. The only problem we have with that approach is that all the time words -- e.g. updated, start, end, etc. -- need to be defined in advance. The goal of having <time term="start" ...> allows us to define one element -- <time...> and allow the term to be open to extension later.
>> 
>> However, we could fix the time elements as you suggest and allow extension to happen with petitions for new time elements in future versions. As I say it I think I like that idea best.
>> 
>> ---
>> Raj
>> The OGC: Making location count...
>> http://www.opengeospatial.org/contact
>> 
>> 
>> On Oct 25, at 3:27 AM, Yarik wrote:
>> 
>>> Hi all!
>>> 
>>>       Sorry for jumping in. Would the following make sense?
>>> 
>>> 
>>> <poi>
>>> 
>>>   <time>
>>>       <updated>2011-10-21T22:10:00+18:00</updated>
>>>            <start>1954-01-01T00:00:00+00:00</started>
>>>   </time>
>>> 
>>> </poi>
>>> 
>>> 
>>> Cheers,
>>> Yarik
>>> 
>>> 
>>> On Mon, 2011-10-24 at 16:37 -0400, Raj Singh wrote:
>>>> OK now I understand what you meant. You're right in your description of what we talked about regarding separation of "administrative" times -- updated, deleted, created -- and other notions of time. I did deviate from this in the data model because this looked more difficult to deal with in code to me:
>>>> <poi>
>>>> <updated>20111021T22:10:00+18:00</updated>
>>>> <time>
>>>>   <value>19540101T00:00:00+00:00</value>
>>>>   <term>start</term>
>>>> </time>
>>>> </poi>
>>>> 
>>>> than
>>>> <poi>
>>>> <time>
>>>>   <value>20111021T22:10:00+18:00</value>
>>>>   <term>updated</term>
>>>> </time>
>>>> <time>
>>>>   <value>19540101T00:00:00+00:00</value>
>>>>   <term>start</term>
>>>> </time>
>>>> </poi>
>>>> 
>>>> However, I'm willing to be convinced otherwise since the former example is less verbose.
>>>> That's why I said flame away! ;)
>>>> 
>>>> ---
>>>> Raj
>>>> 
>>>> On Oct 24, at 3:54 PM, Alex Hill wrote:
>>>> 
>>>>> Raj,
>>>>> I was pointing out that I expected "time" to be an attribute (like "category" and "link") of POIType in the schema (as it is in the data model).
>>>>> There seems to be some disagreement about how we expected "updated", "deleted" and "created" to be handled.
>>>>> I thought they would remain as dateTime attributes of POIBaseType (since they are specific to the provenance/maintenance) and that any number of "time" attributes ("start" and "end") can be added to a POIType.
>>>>> This way, even attributes such as "start" time have a built in mechanism for annotating the time it was updated or even added to the POI.
>>>>> Can we get some more thoughts on which way to go with this (i.e. the current data model diagram or the current schema diagram)?
>>>>> Alex
>>>>> 
>>>>> On Oct 24, 2011, at 3:37 PM, Raj Singh wrote:
>>>>> 
>>>>>> Yes, time is a POITermType (which is an extension of POIBaseType). Why would you expect it to be a POIType? POIType is basically a POI, having a label, description, categories and links. Why would time need to have these things? 
>>>>>> 
>>>>>> I've updated two of my examples here:
>>>>>> http://www.w3.org/2010/POI/wiki/In_the_US
>>>>>> http://www.w3.org/2010/POI/wiki/An_airport
>>>>>> 
>>>>>> And everyone please also post examples, and link to them from the use case page:
>>>>>> http://www.w3.org/2010/POI/wiki/Use_Cases
>>>>>> ---
>>>>>> Raj
>>>>>> The OGC: Making location count...
>>>>>> http://www.opengeospatial.org/contact
>>>>>> 
>>>>>> 
>>>>>> On Oct 22, at 10:39 AM, Alex Hill wrote:
>>>>>> 
>>>>>>> Raj,
>>>>>>> Thanks, this looks awesome.
>>>>>>> I am a little confused about the XML schema; it seems to be saying that "time" is an element introduced by POIBaseType when I would have expected it to come from POIType.
>>>>>>> Alex
>>>>>>> 
>>>>>>> On Oct 22, 2011, at 2:51 AM, Raj Singh wrote:
>>>>>>> 
>>>>>>>> I've added an XML schema file and graphic to the data model page:
>>>>>>>> http://www.w3.org/2010/POI/wiki/Data_Model
>>>>>>>> 
>>>>>>>> The biggest change from previous versions is that I've ***made all attributes into elements.*** This is because I think that makes it easier to convert between XML, JSON and RDF (having written some XML<->JSON<->PHP arrays<->MongoDB translation code over the past couple days. After some deep soul searching (having used XML schema heavily in grad school), I'm coming around to the idea that XML may not be the most popular way to exchange POI information -- JSON and RDF are just as important -- so having XML that may not look very elegant is less important than enabling easy translation between these popular representation models. 
>>>>>>>> 
>>>>>>>> Comments, flames, welcome as always.
>>>>>>>> 
>>>>>>>> Now to re-do all my examples...
>>>>>>>> 
>>>>>>>> -----
>>>>>>>> Raj Singh
>>>>>>>> rsingh@opengeospatial.org
>>>>>>>> +1 (617) 642-9372
>>>>>>>> The OGC: Making location count...
>>>>>>>> http://www.opengeospatial.org/contact
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Oct 21, at 7:10 PM, Raj Singh wrote:
>>>>>>>> 
>>>>>>>>> On second thought, no need for a POITimeType. The time functionality can be handled by POITermType.
>>>>>>>>> ---
>>>>>>>>> Raj
>>>>>>>>> 
>>>>>>>>> On Oct 21, at 6:30 PM, Raj Singh wrote:
>>>>>>>>> 
>>>>>>>>>> new version of the core data model (version 5) posted:
>>>>>>>>>> http://www.w3.org/2010/POI/wiki/Data_Model
>>>>>>>>>> 
>>>>>>>>>> This doesn't change anything if you've been writing sample POIs. It's all internal changes to make the model more elegant. This is hopefully a "feature freeze" version before the next draft publication.
>>>>>>>>>> 
>>>>>>>>>> The classes have been modularized a little more to allow for a new time type, and the "POIControlledVocabularyType" has been change to "POITermType"to make the name easier to say (the phrase controlled vocabulary is still useful when defining what this is). 
>>>>>>>>>> 
>>>>>>>>>> Also, "Abstract" has been taken out of some type names as I found the right way to specify that a class is abstract in UML2 is just to italicize the name.
>>>>>>>>>> 
>>>>>>>>>> And finally, the big addition is a POITimeType, which allows for specially named times to be added to <pois>, <poi> and <location>. The names we have now are "start" and "end". The administrative time types of "updated", "created", and "deleted" are still in the POIBaseType.
>>>>>>>>>> 
>>>>>>>>>> enjoy,
>>>>>>>>>> Raj
>>>>>>>>>> 
>>>>>>>>>> -----
>>>>>>>>>> Raj Singh
>>>>>>>>>> rsingh@opengeospatial.org
>>>>>>>>>> +1 (617) 642-9372
>>>>>>>>>> The OGC: Making location count...
>>>>>>>>>> http://www.opengeospatial.org/contact
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> Alex Hill Ph.D.
>>>>>>> www.alexshill.com
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Alex Hill Ph.D.
>>>>> www.alexshill.com
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>>

Received on Tuesday, 25 October 2011 22:01:40 UTC