We are defining an ontology, and using it to derive a vocabulary, similar to what you see here:
But I am not sure how you define those terms. I think of ontology as the concepts and their relationships, as abstractions, which could be represented in a variety of different ways, and the vocabulary as concrete representations of terms, for example in json-LD, which is our current target. @fosterlynn, on the other hand, never uses the word ontology, but creates class models.
In Linked Open Vocabularies (at the link above) people seem to describe themselves as ontologies or vocabularies somewhat interchangeably.
I am not surprised that the valueflows project is a bit difficult to grasp. It is moving very quickly, as you might have seen from my post saying we were using foaf:agent and then @fosterlynn correcting me that we weren’t anymore (we once were, I had not noticed the change). I’m sending you a discourse message to try to arrange a time and venue.
@toka - please forgive my ignorance, but I don’t know how to find the wiki page you mentioned.
No problem. It is the first post in this thread.
See also Maintained Wiki Mode
That intro regards work that is very old. I add 2 URL. But i don’t feel confortable “correcting” your intro. In fact we are now working in order to provide tools to work the LOD ecosystem. http://www.essglobal.info is something else done previously this work.
Continuing the discussion from Cooperation with ESS Global:
LOV is not a vocabulary. LOV is a database with RDF vocabularies. Our ESSglobal RDF vocab is their registered (see )
In fact as far as I understand you are not defining a Ontology, your are defining a Data Model to describe a reality, a context. When you have your Data Model you will proceed to define what RDF vocabularies you can use to describe that data model (and there maybe you can use our ESSGlobal RDF Vocab for some of your classes and properties - we can discuss that).
I would say that what you are doing is a metadata application profile (see ). You should use a method to develop it, if your are not using any (see ). If you are I would like to know which.
It is not difficult. I juts feel that you are not very well grounded in literature and concepts. That is my feeling, I am sorry if I am being to straight.
 http://dcevents.dublincore.org/IntConf/dc-2013/paper/view/178/81 (there is a new version coming soon)
Yes of course. That is what Bob meant when he said “what you see here”. So we are using the term “vocabulary” in the same way.
I will try to clarify. (I don’t care about the words, but I will try to express it in a way so we can understand each other.) Bob and I started with a proven domain ontology which we have used as a base for more than one software system, some of which are still being used daily. We are not and will not be doing anything around upper ontologies. So yes this could be considered a data model, if you prefer. In addition, Bob has many many years of domain experience in manufacturing and supply chain systems and has contributed to several international standards, including one for the domain ontology that we use. That is the main “ontological” or “data model” input to the valueflows project.
And of course now in a new process of collaboration with other participants, we are discussing and refining the model further. And Bob and I already knew we needed to do that, define a further generalization of what we implemented. The valueflows project is a great way to do that.
We are writing and generating json-ld vocabulary now. And yes, as we continue to work, we will start referencing existing vocabularies. And we would certainly consider ESSGlobal vocab as part of that, since it looks like we are trying to pull in the same direction.
We are not at all well grounded in linked open data, as you can easily tell! Bob and I are both very senior developers, with 3 + decades experience apiece. But we are complete newcomers to LOD. We have one person active in the valueflows project who is knowledgeable in LOD and is tutoring us as best he can. (It was his suggestion that we pull out our references to existing vocabs for now until we get to better understanding and have more time to research it.)
I am interested in your link. But for valueflows, I am not at all worried. Our methods may be more practical and more agile than you like, I don’t know. We are happy with them, and are developing them together as we go based on our various backgrounds and desires for the project. Another project or set of people would of course be different.
Now I understand it all. You are based in a system that already exists and you want to improve it and make it LOD compatible, right?
And since you have already this big data model defined, you are kind of iterating an old process. Interesting. I am very interested in your method (you must have one, everyone has!), maybe I can explain you why I am interested in it in the talk we may have. I am actually interested in the definition of a “Agile kind of Method” for the development of Application Profiles.
An Ontology is in fact similar to a RDF vocabulary. I think that we could say that an Ontology is a complex RDF Vocabulary. For instance Good Relations is an Ontology since it describes the whole reality of the capitalist e-commerce and has a IRI attached to it. Every term is defined on the very same Ontology (ex: gr:BusinessEntity for a class and gr:name for a dataproperty or even gr:offers for a ObjectProperty). DCterms is a RDF vocabulary since it is a simple set of terms, but we could call it also an ontology…
Concerning ValueFlows, in my perception you are developing a metadata application profile, and will probably define a RDF vocabulary to describe some of the terms if you can’t find RDF vocabularies or ontologies that can not do it for you.
In your case vf:Agent is a kind of a gr:BusinessEntity, so you could say that in your ValueFlow RDF vocabulary, vf:Agent is a sub-class of gr:BusinessEntity. It is also a kind of a essglobal:SSEInititative …so you should think well if you need really to define a new term (class) called vf:Agent. If you must, you should relate it to gr:BusinessEntity and probably also to essglobal:SSEInitiative in order to enhance interoperability
In this perspective I don’t understand why you call vf:Agent a RDF vocabulary. The RDF vocabulary is VF, vf:Agent might be a class of that vocabulary.
Did we call vf:Agent a RDF vocabulary? Where? If we did, we certainly don’t think so, and should correct that statement.
In general, however, these is-it-a-vocabulary-or-ontology-or-metadata-application-profile arguments seem to be leading more to misunderstandings than understandings. The conversation becomes circular and can’t get anywhere.
We don’t intend to do that, we intend to use common terms as much as possible. We started out with foaf:Agent, but then backpedaled a bit and decided to work through a lot of examples before deciding if we would stick with it. vf:Agent is a placeholder until we decide which common term to adopt.
We like Good Relations quite a lot, but have some differences. I sketched out some of them here: (but beware, Discourse insists on displaying the wrong part of the page, so you need to click the link to get my comment)
I don’t mean those as criticisms of Good Relations; we have different goals. And I could be misunderstanding. When we think our vocabulary-or-ontology-or-metadata-application-profile-or-whatever is stable enough, we’d like to have a conversation with Martin Hepp, whom we deeply respect, to get his feedback.
Good Relations: we use it in our AP (Application Profile ), among others - I think you should definitely use it too.
vocabulary-vs-ontology is one think. AP is clearly another. There is no doubt on what a AP is, it is very well defined in the literature  ,  and .
As I said, we like Good Relations, and I personally want to use as much of it as fits. I am the domain-experience-person in the valueflows gang, though, and not the LOD creation person.
This is possibly related, or can be inspired by, some of the literature present on this special issue on Designing Things Together: Intersections of Co-Design and Actor-Network Theory.
At least in TransforMap and also as part of a few projects we have submitted within the degrowth networks, we have pushed much of this to socio-technical events such as the VoCamps. Up to now there is no concrete experience from our side, but I would see this as an appropriate way of co-designing (with the target communities) the data models and/or ontologies, in a way that reflects their own particular narratives.
4 posts were merged into an existing topic: Participation in Digital Social Innovation
Placemaking and Places in th making
@mariana, I have found a minor problem in the DCAP-SSE spec (VCARD:street-addressglobal). It is reported in an issue on github: https://github.com/p6data-coop/ise-linked-open-data/issues/3. I’m posting this here because I want to keep discussions about ESS Global visible by the TransforMap community. Perhaps you could comment either here, or in the github issue?
I have to look it with more time. It can be a typo or a very stupid error. I note that this work has never been validated. You are the validators if you decide to use the model. So this is already so good that you are paying attention to details and trying to understand! I will come back asap with a comment.
Today via email I got a hint to have a deeper look the SSEDAS partner CERAI, which had their network find the socioeco map and request if there is collaboration. It would be great to join forces for the benefit of mapping the SSE movement.
socioeco.org is already with ESSglobal and evolving its format. So all
forms of collaboration are welcome!
that is great, who is the contact person to get into conversation about collaborating with http://www.socioeco.org/solutions_es.html?
About the possible collaboration within the frame of ESS Global it would be great to have a conversation in the next 10 days.