Re: update to data model and Time specifications to reuse in POI

Hi, Raj!

Ok, I somehow assumed that there is only one VCARD entry per <author>. 

>In this way we cover 99% of cases. The only exception is if someone
>felt the need to have authors listed on the same level but wanted to
>describe some with VCard and others with free text. But this should
>never happen. If you know how to create a VCard entry, you shouldn't
>have a problem doing it for all your authors.

Agree.

Greets,
Yarik

On Fri, 2011-11-04 at 14:22 -0400, Raj Singh wrote:
> One note. I'm changing the MIME type from text/directory to text/vcard according to RFC 6350. Is this a good idea or is 6350 only for VCard version 4.0?
> http://tools.ietf.org/html/rfc6350
> 
> I really think it would be odd to have only one property of POIBaseType be repeatable. 
> 
> Yes your example is valid. If you really need to have mltiple authors listed on the same hierarchy level, it's obviously easy to do with free text, but with VCard how about putting multiple VCards in the author element, like this:
> 
> <poi> (<time><link><license><label>)
> <author>
>  <type>text/vcard</type>
>  <term>primary</term>
>  <value>
>   BEGIN:VCARD
>   END:VCARD
>   BEGIN:VCARD
>   END:VCARD
>  </value>
> </author>
> </poi>
> 
> In this way we cover 99% of cases. The only exception is if someone felt the need to have authors listed on the same level but wanted to describe some with VCard and others with free text. But this should never happen. If you know how to create a VCard entry, you shouldn't have a problem doing it for all your authors.
> 
> ---
> Raj
> The OGC: Making location count...
> http://www.opengeospatial.org/ogc/organization/staff/rsingh
> 
> 
> On Nov 4, at 8:40 AM, Yarik wrote:
> 
> > Hi Raj!
> > 
> >> I changed this to allow for multiple descriptions.
> > This is cool since now I can have poi descriptions in multiple langs.
> > 
> >> I also changed author to 0..1 instead of 0..*. This makes relational
> >> database implementations a little easier, and author can be nested
> >> within author, so this should be just as flexible as before
> > 
> > Would this snippet be valid then?
> > <poi> (<time><link><license><label>)
> > <author>
> >  <type>text/plain</type>
> >  <term>primary</term>
> >  <value>F. Gump</value>
> >  <author>
> >   <type>text/directory</type>
> >   <term>secondary</term>
> >   <value>VCARD</value>
> >  </author>
> > </author>
> > </poi>
> > This structure might provide a way to define multiple authors as before
> > but I would argue that it would be as informative as having 0 .. *. Me
> > this construction tells that a poi has an author and that author was
> > created by the secondary author. 
> > This might be just narrow-minded me, though.
> > 
> > I don't find modeling of 0 .. * relation for the author a big deal. What
> > complicates it is the recursion (that author has an author). Is this
> > relation crucial? 
> > 
> > Cheers,
> > Yarik
> > 
> > 
> > On Mon, 2011-10-31 at 09:52 -0400, Raj Singh wrote:
> >> I put some thought into the time object this weekend. As Karl says, we want to keep it pretty simple as core POI should be a least-common-denominator standard that is accessible to every information community. I added a time term of "instant" based on the KML TimeStamp. I didn't see a pressing need to anything from GML.  
> >> 
> >> Working with the model I also noticed that we were limiting description to none or one value. I changed this to allow for multiple descriptions. I also changed author to 0..1 instead of 0..*. This makes relational database implementations a little easier, and author can be nested within author, so this should be just as flexible as before. I also made author a POITermType so that we could tag it with terms like primary, secondary, contributor, editor. etc.
> >> 
> >> As always, it's posted to:
> >> http://www.w3.org/2010/POI/wiki/Data_Model
> >> 
> >> ---
> >> Raj
> >> The OGC: Making location count...
> >> http://www.opengeospatial.org/contact
> >> 
> >> 
> >> On Oct 27, at 4:08 PM, Seiler, Karl wrote:
> >> 
> >>> To bring us back to the primary use cases for time let's review the need, to ensure we are not over/undersope:
> >>> 
> >>> 1. point in time for status changes - created on..., updated on..., delete on...
> >>> 2. periods of time for place/location events - "Taste of Chicago" starts on... ends on... is bounded by this area...
> >>> 3. collections of periods of time - hours of operations - closed Sun-Mon, open 8-6 T-F, open 10-2 Sat...
> >>> 
> >>> 
> >>> _______________________________
> >>> Karl Seiler
> >>> Director Location Technology & Services
> >>> NOKIA Location and Commerce - Chicago
> >>> (T)  +312-894-7231
> >>> (M) +312-375-5932
> >>> 
> >>> 
> >>> -----Original Message-----
> >>> From: Yarik [mailto:Iaroslav.Sheptykin@hs-bremen.de]
> >>> Sent: Thursday, October 27, 2011 2:18 PM
> >>> To: public-poiwg@w3.org W3C
> >>> Cc: Raj Singh
> >>> Subject: Time specifications to reuse in POI
> >>> 
> >>> Hi everyone!
> >>> 
> >>>       In one of the last emails Raj has found the idea of having a
> >>>       review of time specs good.
> >>>       http://lists.w3.org/Archives/Public/public-poiwg/2011Oct/0029.html
> >>> 
> >>>       I gave it a try but didn't go far. I have started from taking a
> >>>       look what GML and KML did in support of temporal attributes of
> >>>       their data.
> >>> 
> >>>       KML has two time types: TimeStamp and TimeSpan. Both extend
> >>>       abstract TimePrimitive. TimePrimitive is included into the
> >>>       Feature type and inherited by PlaceMark, NetworkLink, Overlays,
> >>>       Folder and Document. The geometry is not temporally enabled.
> >>>       more at
> >>>       http://code.google.com/apis/kml/documentation/kmlreference.html
> >>>       Learning from KML we could add an abstract type Time to the
> >>>       POIBaseType. Created, Modified, Deleted could extend Time. We
> >>>       could allow Created and Deleted appear 1 and 0..1 respectively
> >>>       within its parent. Modified could appear 0 .. *. Ex:
> >>> 
> >>>               <created>...</created>
> >>>               <modified id="" />...</modified>
> >>>               <modified id="upgraded">...</modified>
> >>>               <modified id="rebooted">...</modified>
> >>>               <modified id="decorated">...</modified>
> >>>               <deleted>...</deleted>
> >>> 
> >>>       GML takes it more seriously. Similarly to KML it has TimeInstant
> >>>       and TimePeriod types. Additionally it allows defining relations
> >>>       between time instances. It implements calendars.
> >>>       GML Temporal XSD
> >>>       http://schemas.opengis.net/gml/3.2.1/temporal.xsd
> >>>       Learning from GML we could consider using calendars and
> >>>       relations. Also, as the model already suggest, we could add
> >>>       temporal dimension to the geometry as well, which I believe GML
> >>>       developers would find a great idea.
> >>> 
> >>>       I am interested in reviewing other sources such as standards or
> >>>       papers which provide guidelines for the temporal modeling. If
> >>>       you have any in mind, or know a community that could provide
> >>>       further hits please share. I could summarize it afterwards in a
> >>>       wikipage.
> >>> 
> >>> Greets,
> >>> Yarik
> >>> 
> >>> 
> >>> 
> >>> The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited.  If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
> >> 
> >> 
> > 
> > 
> > 
> 
>

Received on Friday, 4 November 2011 22:07:02 UTC