Re: Email Message Definition?

On 5/16/14 3:23 PM, Dan Brickley wrote:
> On 16 May 2014 19:32, Kingsley Idehen<>  wrote:
>> >On 5/16/14 1:27 PM, Dan Brickley wrote:
>> >On 16 May 2014 17:59, Kingsley Idehen<>  wrote:
>>> >>Is this [1] the definition of an Email, or this just an error?
>> >
>> >"An email message."
>> >
>> >Short and sweet. Is there more that you think it should usefully say?
>> >
>> >At this stage we have not got into the business of representing mail
>> >headers, although that could turn out to be interesting.
>> >
>> >Dan
>> >
>> >
>> >But I am not seeing a single recognizable Email Message attribute, hence my
>> >question. Another route to my confusion is by using a CTRL+F (or Command F)
>> >sequence to search on the pattern: Email, there are only two hits:
>> >
>> >Thing > CreativeWork > EmailMessage
>> >An email message.
>> >
>> >The properties table doesn't have a single hit i.e., its basically describes
>> >a 'Creative Work' .
>> >
>> >Hoping this clarifies my concerns.
> Ah, sure. In many classic modeling setups, it is a perfectly good rule
> of thumb to say "don't create a subtype unless you have something new
> to say!". And certainly some areas of do seem to go deeper
> than was needed. But I think here we can be excused, as there are
> other reasons that favour the addition of named types sometimes, even
> without (initially) populating them with properties.
> However, talking about EmailMessage: it is essentially a sibling to
> accompany  and serves to indicate the
> evolution of from being primarily about Web markup, to also
> addressing markup-via-email, e.g. the recently announcement from
> Bing/Cortana  or
> last year's gmail launch which used EmailMessage (and an early draft
> of the Actions schema), e.g.
> In the case of EmailMessage it might make sense in future to go deeper
> and model more email structure, but even having a simple type and no
> properties can be useful. For another (google) use of named
> types,
> lets you create custom search engines keyed off of the type name.
> Here's one I made to search the (small!) number of sites that use
>  :
> ... The current "make a custom search engine" UI has special case
> support for concepts that are types (e.g. Volcano, ...), but not for
> complex expressions using types alongside qualifying properties (Place
> + volcanicity=true ...).
> For's uses, the fact that types get a nice simple syntax in
> HTML makes them attractive, even if you could theoretically model
> things better using a supertype + additional properties.
> A final point: although might not yet define properties for
> the EmailMessage type, it does provide an attachment point for others
> to do exactly that. And if those properties were popular, we could go
> ahead and reflect them into
> cheers,
> Dan

I get the point re. just having a Type, but in reality, there's always 
at least one attribute, even it it boils down to what's expressed here:

## Turtle Start ##

<> rdfs:subClassOf 
<> .
<> a owl:Class .
<> rdfs:label "EmailMessage" .
<> rdfs:comment "An email message".

## Turtle End ##

Which for all intents an purposes boils down to adding a comment 
attribute to the <> properties table. 
Net effect,  the sentence "An email message." and label "EmailMessage" 
become  distinguishing attributes of the class in question.



Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter Profile:
Google+ Profile:
LinkedIn Profile:

Received on Friday, 16 May 2014 21:42:01 UTC