- From: Raj Singh <rsingh@opengeospatial.org>
- Date: Wed, 8 May 2013 20:12:07 -0400
- To: Dan Brickley <danbri@danbri.org>
- Cc: "public-vocabs@w3.org" <public-vocabs@w3.org>
So the 'about' property refers to a 'Thing'. This is nice as most of what I want to do with a tag (or classification system) is supported by Thing. So maybe the short answer is to move the 'about' property up to 'Thing'. But let me ask if the semantics are right. The dublin core subject talks about using subject for classification codes, which is a strong use case of mine. For example, a restaurant might be tagged with its north american classification code [1] and its european one [2]. If its old and famous it might also be tagged as a 'historic landmark' and a 'tourist attraction'. Are those 4 tags really 'Thing's? If so, and the community is comfortable with that idea, than the CreativeWork 'about' property can work. [1] http://www.census.gov/eos/www/naics/ [2] http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm?TargetUrl=LST_NOM_DTL&StrNom=NACE_REV2&StrLanguageCode=EN&IntPcKey=&StrLayoutCode=HIERARCHIC&CFID=12721637&CF --- Raj The OGC: Making location count. http://www.opengeospatial.org/ogc/organization/staff/rsingh On May 8, at 7:33 PM, Dan Brickley <danbri@danbri.org> wrote: > On 9 May 2013 00:30, Raj Singh <rsingh@opengeospatial.org> wrote: >> I suppose that's a fair summary. But I wasn't proposing going so far as the flexibility of the concept system of SKOS. I was thinking more along the lines of Dublin Core's subject [1] (my original reference was to Atom's category, which has roots in Dublin Core's subject). >> >> [1] http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#terms-subject > > Our equivalent to dc:subject is, roughly, the 'about' property on a > CreativeWork. For non-creative works, how would subject categories > compare to our existing type system? (Noting that RDFa Lite allows > multiple types to be written nicely, and we added 'additionalType' to > allow multi-namespace multiple typing when using the Microdata > notation). > > Dan > >> --- >> Raj >> The OGC: Making location count. >> http://www.opengeospatial.org/ogc/organization/staff/rsingh >> >> >> On May 8, at 7:09 PM, Dan Brickley <danbri@danbri.org> wrote: >> >>> On 9 May 2013 00:00, Raj Singh <rsingh@opengeospatial.org> wrote: >>>> I haven't heard anything on this for a month. I think Dan was on vacation the week it was discussed, which may be part of the problem. Dan, could you comment? >>> >>> This one did escape me. Is this a fair summary: >>> >>> 1. there is support for sameThingAs (or 'sameAs'; I'm more and more >>> convinced to go with OWL-compatible naming). >>> 2. there is interest in a categorisation mechanism that operates at a >>> different level to schema.org's built-in typing system; something >>> close to W3C SKOS? >>> >>> Dan >>> >>>> --- >>>> Raj >>>> The OGC: Making location count. >>>> http://www.opengeospatial.org/ogc/organization/staff/rsingh >>>> >>>> >>>> On Apr 10, at 1:37 PM, Raj Singh <rsingh@opengeospatial.org> wrote: >>>> >>>>> I had two proposals. One was category and the other was related link. sameThingAs is one type of related link -- the most important type IMHO. So I agree it does not replace the need for category. I still suggest adding that property to Thing. >>>>> >>>>> --- >>>>> Raj >>>>> >>>>> On Apr 10, 2013, at 11:40 AM, Karen Coyle <kcoyle@kcoyle.net> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 4/9/13 3:40 PM, Raj Singh wrote: >>>>>>> Reading the sameThingAs property [1], I do think that would serve >>>>>>> mainly the same purpose. Thing/link as I described it would be more >>>>>>> general, allowing for more types of relationships between the >>>>>>> resource and the link, but honestly, I think sameThingAs covers most >>>>>>> requirements. >>>>>> >>>>>> I see a difference between the identification role of sameThingAs and Raj's proposal for a property that can be used to categorize something. This is based on my assumption that a category for the church named "Sagrada Familia" might be a link to the wikipedia category "Churches in Barcelona" or the geonames code "CH" for "church." If sameThingAs also exists as a property, then the link to dbpedia:Sagrada_familia would use that property. >>>>>> >>>>>> I wouldn't expect to see sameThingAs -> geonames:CH. >>>>>> >>>>>> Raj, have I understood your meaning of "category"? >>>>>> >>>>>> kc >>>>>> >>>>>>> >>>>>>> I don't think Thing/url could be made to work for this purpose. You >>>>>>> could do some mark up like that below, but the semantics would be too >>>>>>> vague to do anything with it. >>>>>>> >>>>>>> <div itemscope itemtype="http://schema.org/Place"> <p >>>>>>> class="headline" itemprop="name">First Baptist Church in America</p> >>>>>>> <a href="picinside.html" itemprop="url">Here is a picture inside the >>>>>>> church</url> <a href="picback.html" itemprop="url">Here is a picture >>>>>>> of the back of the church</url> <a href="church.rdf" >>>>>>> itemprop="url">This is some RDF about the church</url> </div> >>>>>>> >>>>>>> Just the fact that they are called out as "urls" about the place >>>>>>> could tell you that there's some relationship (but the documentation >>>>>>> would have to make this clear) between the Thing and its child "url" >>>>>>> properties. Is that enough semantics for the schema.org mission? >>>>>>> Until now I didn't think it was, but maybe it is. It's a good debate >>>>>>> to have... >>>>>>> >>>>>>> [1] http://www.w3.org/wiki/WebSchemas/ThingIdentity >>>>>>> >>>>>>> --- Raj The OGC: Making location count. >>>>>>> http://www.opengeospatial.org/ogc/organization/staff/rsingh >>>>>>> >>>>>>> >>>>>>> On Apr 9, at 5:55 PM, Justin Boyan <jaboyan@google.com> wrote: >>>>>>> >>>>>>>> Raj, re your second proposal, can you clarify the difference >>>>>>>> between Thing/link, the existing Thing/url, and the object's id >>>>>>>> (microdata @itemid, RDFa @about)? Would Thing/link serve the same >>>>>>>> purpose as the proposed sameThingAs property? >>>>>>>> >>>>>>>> Thanks, Justin >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Apr 9, 2013 at 5:03 PM, Raj Singh >>>>>>>> <rsingh@opengeospatial.org> wrote: I'm developing schema.org schema >>>>>>>> for points of interest (POIs), based on a lot of work on a >>>>>>>> conceptual model [1]. I've created an initial implementation using >>>>>>>> existing schema.org vocabulary -- particularly the Place object >>>>>>>> [2]. >>>>>>>> >>>>>>>> Two things seem to be omitted from the core schema, which are key >>>>>>>> components of our POI model. First is the idea of categorization, >>>>>>>> or freeform tagging, such as is present in the Atom category >>>>>>>> element [3]. This is a concept used in the POI model, but seems >>>>>>>> incredibly useful for any type of object, and therefore I believe >>>>>>>> category should be a property of Thing. >>>>>>>> >>>>>>>> Second is the idea of related links. The concept of identifying >>>>>>>> related resources is a widespread requirement present in most >>>>>>>> information architectures. HTML has it [4]. Atom has it [5]. >>>>>>>> Semantic technology such as RDF is practically based on it. Why not >>>>>>>> schema.org? In the POI work, we adopted the IANA link relation >>>>>>>> types [6], but we weren't totally happy with those. Doesn't it seem >>>>>>>> like schema.org's Thing needs a link property? >>>>>>>> >>>>>>>> >>>>>>>> [1] http://www.w3.org/2010/POI/wiki/Data_Model [2] >>>>>>>> http://openpois.ogcnetwork.net/pois/51f2e335-781e-4651-bfe2-d54682238919 >>>>>> [3] http://www.atomenabled.org/developers/syndication/#category >>>>>>>> [4] >>>>>>>> http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html#h-12.3 >>>>>> [5] http://www.atomenabled.org/developers/syndication/#link >>>>>>>> [6] >>>>>>>> http://www.iana.org/assignments/link-relations/link-relations.xml >>>>>>>> >>>>>>>> --- Raj The OGC: Making location count. >>>>>>>> http://www.opengeospatial.org/ogc/organization/staff/rsingh >>>>>> >>>>>> -- >>>>>> Karen Coyle >>>>>> kcoyle@kcoyle.net http://kcoyle.net >>>>>> ph: 1-510-540-7596 >>>>>> m: 1-510-435-8234 >>>>>> skype: kcoylenet >>>>>> >>>>> >>>> >>>> >> >
Received on Thursday, 9 May 2013 00:12:38 UTC