Re: Proposal for new type : Vocabulary

Dear Martin and all,

This is an excellent initiative (+1).  Providing Schema.org models and 
syntax specs will really help many developers to understand this 
vocabulary. Nevertheless will also contribute to the improvement and 
refactoring of this vocabulary.

Either a visual solution (MOF on top of UML infrastructure) or a 
text-based representation would not be easy to be maintained as the 
vocabulary is still developing fast.

However an online  collaborative platform for UML modeling may be a 
solution to distribute the effort.

Regards,
Adrian

On 12/11/2013 7:44 PM, Martin Hepp wrote:
> Hi all:
>
> My proposal is that we try to define a proper meta-modeling part for schema.org and externalize that. I understand that for historic reasons, schema.org was designed to be self-contained, with a minimal coupling to external standards (except for syntaxes like Microdata or RDFa).
>
> Now, however, with a lot more thrust behind everything, it would be nice to have a clear stack of
>
> 1. Syntaxes (Microdata, RDFa, and JSON-LD)
> 2. A meta-model (all schema.org elements for expressing conceptual structures) (MOF level M2 and maybe M1, http://en.wikipedia.org/wiki/Meta-Object_Facility)
> 3. A domain model (i.e. most of what schema.org is about) (MOF level M3).
>
> It is not necessary to use two distinct namespaces for #2 and #3, but I think we should take the time to clean up and specify this distinction, because all elements from the meta-model part should be reused as much as possible by all domain-specific parts of the vocabulary.
>
> It will not harm too much if, in the future, we will have some degree of overlap and even conflicts between different branches of the domain vocabulary; in fact I assume that it is impossible to keep schema.org fully consistent down to the finest level. But the meta-model core should be used consistently.
>
> The vocabulary part, the modeling of quantities from GoodRelations, the Topic extension, and the proposed notion of Vocabulary belong to #2, IMO.
>
> Just my two cents.
>
> Martin
>
> On Dec 7, 2013, at 2:28 PM, Antoine Isaac wrote:
>
>> Hi Chaals, all (I guess there was a problem in my email's receipients)
>>
>> I think I'm in favour of having owl:Ontology, and if there's a need to get an umbrella for glossaries/thesauri/other classifications, to re-use skos:ConceptScheme or something like that.
>>
>> Diane says there are use cases, but http://metadataregistry.org/ still makes a big difference between "Vocabularies"  (there, akin to SKOS ConceptSchemes) and "Element Sets" (there, akin to OWL Ontologies).
>> In fact Bernard has not answered my question on starting to have everything in LOV.
>>
>> To be more precise: I do not see the the use case for having *only* the generalization of Ontology and ConceptScheme. I see the point in making inventories of both types of resources; but because the two categories are usually made to meet quite different requirements, I'm skeptical about the value of blurring the line.
>>
>> About rdfs:isDefinedBy vs an hypothetical "uses" property (between Vocabulary and individual classes/properties or concepts). I agree with Chaals: the differences may not survive in this case. More precisely: I think it is the "usage" link between vocs and their elements that will get more traction. The "defined" link is more a provenance/process aspect; it's important for specific scenarios, which may not be really sought by the general schema.org users. Therefore it would seem dangerous to me to use rdfs:isDefinedBy, because its original meaning would be 'highjacked' by the more prominent requirement.
>>
>> Antoine
>>
>> On 12/6/13 9:46 PM, Charles McCathie Nevile wrote:
>>> On Fri, 06 Dec 2013 11:19:06 +0100, Antoine Isaac <aisaac@few.vu.nl> wrote:
>>>
>>>> Hi Bernard,
>>>>
>>>> +1 for including Vocabulary. It would fill in the gap of not having included an equivalent to skos:ConceptScheme in the MiniSKOS proposal.
>>>> I'm however a bit skeptical about having just one class for ontologies (sets of classes and properties a la schema.org) and other SKOS-level vocabularies (classifications, thesauri) in one big bag. I'll be the first one to agree with you that the two types of vocabularies are not exclusive. But the functions are quite different.
>>> I'm not so sure - and I certainly don't know of a practical way to describe the difference to non-professionals.
>>>
>>>> In fact trying a litmus test: if the "Vocabulary" class was to include SKOS Concept schemes, would the Linked Open vocabularies start gathering SKOS concept schemes as well?
>>> That would seem like a reasonable thing to me. Although they might be selective about them for other reasons.
>>>
>>>>> An extra would be to have a "definedBy" property to link instances of the oncoming Topic class to an instance of Vocabulary.
>>>>>
>>>> Is this skos:inScheme in the SKOS world, or really rdfs:isDefinedBy?
>>>> The nuance (creating vs. including/re-using) can be in fact really important. (and I personally feel that both aspects are worth representing).
>>> The problem is that in practice, where a term is originally defined stops being relevant once people start including it in other places with differences, and getting traction.
>>>
>>> I have nothing in principle against preserving the differences, but I am sceptical that they will survive contact with reality, and not sure they are worth struggling for.
>>>
>>> cheers
>>>
>>> Chaals
>>>
> --------------------------------------------------------
> martin hepp
> e-business & web science research group
> universitaet der bundeswehr muenchen
>
> e-mail:  hepp@ebusiness-unibw.org
> phone:   +49-(0)89-6004-4217
> fax:     +49-(0)89-6004-4620
> www:     http://www.unibw.de/ebusiness/ (group)
>           http://www.heppnetz.de/ (personal)
> skype:   mfhepp
> twitter: mfhepp
>
> Check out GoodRelations for E-Commerce on the Web of Linked Data!
> =================================================================
> * Project Main Page: http://purl.org/goodrelations/
>
>
>
>
>
>

-- 
-Adrian Giurca
Twitter <http://www.twitter.com/giurca>
LinkedIn <http://www.linkedin.com/in/adriangiurca>