What is the relationship (if any) between BFO and https://schema.org?

[James Hudson]

I am still new to this space and wasn't sure what the answer to this question would be.

Would schema.org be considered part of BFO or are they charting their own path?

[Barry Smith]

I would say that each is charting its own path. Schema.org is somewhat more lightweight, logically speaking. 
BS

On Fri, Jun 12, 2020 at 3:11 PM James Hudson <jameshu...@gmail.com> wrote:

I am still new to this space and wasn't sure what the answer to this question would be.

Would schema.org be considered part of BFO or are they charting their own path?

--
You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/db74dd46-ae11-401b-bde7-8cd45bfb8c5do%40googlegroups.com.

[James Hudson]

Interesting. 

If this will spark a flame or other kind of internet war, please ignore the question, but I am curious as to why https://schema.org did not join with BFO.

On Friday, June 12, 2020 at 3:14:45 PM UTC-4, Barry Smith wrote:

I would say that each is charting its own path. Schema.org is somewhat more lightweight, logically speaking. 
BS

On Fri, Jun 12, 2020 at 3:11 PM James Hudson <jameshu...@gmail.com> wrote:

I am still new to this space and wasn't sure what the answer to this question would be.

Would schema.org be considered part of BFO or are they charting their own path?

--
You received this message because you are subscribed to the Google Groups "BFO Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bfo-d...@googlegroups.com.

[Mathias Brochhausen]

So, if you look at the purpose of schema.org it says:

"Schema.org is a joint effort, in the spirit of sitemaps.org, to improve the web by creating a structured data markup schema supported by major search engines. On-page markup helps search engines understand the information on web pages and provide richer search results. A shared markup vocabulary makes easier for webmasters to decide on a markup schema and get the maximum benefit for their efforts. Search engines want to make it easier for people to find relevant information on the web. Markup can also enable new tools and applications that make use of the structure."

This is not the purpose of BFO. Others might know better, but BFO, in my mind, is an upper ontology to support the development of ontologies as part of the knowledge representation paradigm. While BFO can be and has been implemented in other knowledge representation languages, a lot of work using BFO is currently using the Web Ontology Language (OWL), which is itself part of a knowledge representation methodology called Semantic Web.

Ontologies can be used to do markup and in that sense BFO might look like a schema, but that is not the purpose of developing, implementing and using ontologies (in my mind). BFO might, in practise, look much like schema.org, but from an engineering point of view it does serve a different purpose.

Best,

Mathias

To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/fce1f54a-fd45-4f98-b940-1362b214679bo%40googlegroups.com.

[Chris Mungall]

[fetches popcorn]

To make this more productive, why not turn it around: propose what schema.org would gain by joining with BFO, and define what it actually means to join with BFO

To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/fce1f54a-fd45-4f98-b940-1362b214679bo%40googlegroups.com.

[James Hudson]

I agree, your questions are better. Pretend I asked that one instead. Hopefully popcorn will not be needed.

On Friday, June 12, 2020 at 3:35:02 PM UTC-4, Chris Mungall wrote:

[fetches popcorn]

To make this more productive, why not turn it around: propose what schema.org would gain by joining with BFO, and define what it actually means to join with BFO

On Fri, Jun 12, 2020 at 12:24 PM James Hudson <jameshu...@gmail.com> wrote:

Interesting. 

If this will spark a flame or other kind of internet war, please ignore the question, but I am curious as to why https://schema.org did not join with BFO.

On Friday, June 12, 2020 at 3:14:45 PM UTC-4, Barry Smith wrote:

I would say that each is charting its own path. Schema.org is somewhat more lightweight, logically speaking. 
BS

On Fri, Jun 12, 2020 at 3:11 PM James Hudson <jameshu...@gmail.com> wrote:

I am still new to this space and wasn't sure what the answer to this question would be.

Would schema.org be considered part of BFO or are they charting their own path?

--
You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/db74dd46-ae11-401b-bde7-8cd45bfb8c5do%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/fce1f54a-fd45-4f98-b940-1362b214679bo%40googlegroups.com.

[Ludger Jansen]

Given that Mathias is right (which I think he is), there can nevertheless be points of contact between schema.org and BFO. Classes in schema.org could be connected to BFO (and to other OBO ontologies, like IAO!), and relations/properties could be re-engineered in the light of the BFO-standard. This would give schema.org additional semantic power and increase its interoperability with other standards.

Best
Ludger

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAAUMtwDePrhRejUH8Jab_P5RRZMCNy_yemBV4Sswzxu6_qO_HQ%40mail.gmail.com.

-- 
Prof. Dr. Ludger Jansen
Vertreter des Lehrstuhls für Philosophie
Universität Passau
D-94030 Passau

Privatdozent 
Institut für Philosophie
Universität Rostock
D-18051 Rostock

[Barry Smith]

My assumption is that, assuming they even considered the question, they thought that they did not need the extra logical complexity which BFO would have provided.
BS 

To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/fce1f54a-fd45-4f98-b940-1362b214679bo%40googlegroups.com.

[Bill Hogan]

My understanding of schema.org was to fit a "bit of semantics" into traditional HTML to help search engines perform better.  BFO is aimed at structured data, at least more so than it is text data, let alone HTML specifically, let alone search engines even more specifically.

That said, these are good points about potential ways they could work together, if indeed that were an objective someone were working on.

Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAN_82ST6er5%3Dn7Jj7KH-Eq5OBgWKQcDd-_atO_RcmuVKc5b4aA%40mail.gmail.com.

[Pierre Grenon]

Hi,

they are different things and at the end of the day people use what they find ^^ with schema.org you get coverage of broadly organised types of stuff you find on the internet. Schema.org evolved as a practical collection and seems family related to the old SUMO endeavours. 

I don't have a great command of schema.org principles and methodology but some seem to be at odd with BFO, e.g. multiple inheritance seems to occur and intuitively it seems not unrelated to inherent polysemy of terms in natural language --- not just logical construction. There is a noticeable mixing of things and representation either in types or their documentation, perhaps only at the higher levels, I do not know in details. It seems not uncommon to see thematic roles turned into types (e.g., patient). The hierachy of types is a typical property oriented one. 

Barry's comment about logical complexity seems right, yet it does seem to extend to ontological complexity as well. While types in schema.org have slots of sorts and they are inherited and so on, it does not look much aimed at a knowledge representation rather than a classification. 

If you were to propose applying a BFO cookie cutter to the schema.org hierarchy, you'd probably struggle with their 'intangible', the handling of tropes and stuff like that but it's not like you'd add more to it than by expanding and refining its domain coverage.

In terms of coverage, perhaps a more interesting comparison is with the Common Core Ontologies since that and schema.org are about what we'd charitably call mid-level. This also gives you a better angle to ask about the comparison between a small, somewhat sophisticated formal ontology and a broad and opportunistic coverage mid levelish type hierarchy. 

There are of course plenty of interesting questions arising as soon as you start to look into specific cases but they are just plain ontological questions. 

best wishes,

Pierre 

Le ven. 12 juin 2020 à 20:11, James Hudson <jameshu...@gmail.com> a écrit :

I am still new to this space and wasn't sure what the answer to this question would be.

Would schema.org be considered part of BFO or are they charting their own path?

--
You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/db74dd46-ae11-401b-bde7-8cd45bfb8c5do%40googlegroups.com.

[Asiyah Yu Lin]

Great discussion!

The pilot of converging or making schema.org gain by joining BFO may start from here:

https://public.nihdatacommons.us/DCPPC-DRAFT-7_KC2/#core-metadata-principles  

NIH's data commons decided to use schema.org, and below is what it is said in the documentation:

The decision to use schema.org as the metadata schema used for core metadata was based on the following:

1. Schema.org is supported by GUIDs used in the Data Commons Pilot, and mappings exist to other metadata standards used in the Data Commons Pilot, in particular DATS.[4]

2. Schema.org is widely adopted outside the Data Commons Pilot, with a large number of services and tools available.

3. Schema.org supports all metadata fields required for core metadata, so that no schema updates are needed during the pilot. We have identified at least one metadata field (checksum) that would benefit from extra work, and we have reached out to the schema.org community to work on this after the Data Commons Pilot.

Thanks,

Asiyah

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAAkf34zWA-y1PSJ5%3DQtHzxfTwUTNtaoQR%2BvfhHYqrJR17C%2BajQ%40mail.gmail.com.

[Pierre Grenon]

Interesting link --- I wasn't familiar with this personally so apologies if the following is naïve --- Has this resulted in something beyond a proof of concept for FAIRness, do you know? 

However, in relation to the discussion, the items you quoted are about a metadata solution --- that programme picked a solution to metadata management requirements --- I guess here the comparison was with things like dublin core? 

I think some of the comments made by Mathias or Ludger may be more in the spirit of saying BFO, or it's varied domain extensions are intended with something closer to what's described in the principles on the page you linked. 

6. Extended metadata for describing a dataset are outside the scope of this document and will be addressed elsewhere, in particular in KC7. Extended metadata includes information about the (scientific) contents of the data object. The KC2 core metadata described here is a subset of KC7 metadata.

Furthermore, this extended -- domain -- vocabulary, any annotational schema it may be used with, provides descriptional hooks of resources. These hooks are entry points in a domain knowledge representation that the BFO type stuff is fundamentally about --- I think that was Mathias point (although I dont think it's a technology point). 

Do you know about this KC7 and whether schema.org had been found sufficient for this broader scope? Was that capability tested? Do you know the level of inferences involved in powering the search?

With many thanks and kind regards,

Pierre

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CADBWCHYNjRWV45qUB0pgjyJ0Ln1siHtPaJF%3D9QGxBmdED%2B6MpA%40mail.gmail.com.

[Asiyah Yu Lin]

Hi Pierre,

I have heard that schema.org is going to be used for finding datasets in NIH's Data Science talks.  I will reach out to NIH data science strategy office to check it out and hopefully I will be given an answer.

Please also check http://bioschemas.org/ and ELIXIR (originated from EBI), as they are related. I had raised this question to ELIXIR people who were presenting the idea of interoperability about how to consolidate the schema.org and ontologies. I didn't get a clear answer. Perhaps this paper will help https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5460592/

Thanks,

Asiyah

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAAkf34xOzFLvfspx8Hzp7DKb0L0DXv370cqqAV_fP80kFOTEqA%40mail.gmail.com.

[Pierre Grenon]

Thanks for the follow up. 

Kinda makes sense. I don't know if this bears any actual relation to biomodels qualifiers but it seems conceptually related --- maybe more generic and systematic. 

The concern of course is then how this stuff lives together with GO, CHEBI and so on. 

Many thanks,

Pierre

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CADBWCHY3nu5kh%3DR_Vfg3yp26zs9hYTypVgj5r8At1BO621CE8g%40mail.gmail.com.

[Philippe]

Dear All,

A couple of comments based on our experience developing DATS  [1] and working with Bioschema (as part of Elixir) [2]

1. schema.org serves the purpose of 'Discoverability' owing to its use for search engine optimitization and page markup.

2. schema.org has almost no 'official' coverage for anything bio-related, hence the proposal and work by the Bioschema, to add new types (gene, protein, chemical entity, workflow...)

The only Types that were quickly uptaken by schema.org were 'Dataset' [3], 'DataCatalog', owing to the obvious needs present at the time (2 years ago) around dataset indexing.

There is nothing (to my knowledge) to talk explicitly about Taxonomy(*), Anatomical location (but there are Bioschema proposals for those ).

The Medical study extension of schema.org allows to supply Taxonomic information explicitly only in the context of describing pathogen agent.

It will be interesting to see how the covid-19 crisis will change the views on how important Bio things are.

I presume you all saw the quick release of schema.org terms for covering US CDC case reports/counts [4] .

So we can hope that the draft Bioschema types will be included rather soon. They have at the doorstep of schema.org for quite some time, which has not stopped some resources to start annotating their pages with those types and purpose built crawlers exist.

3. DATS was released from the onset with 2 sets of json-ld context files:

-one providing a mapping of the objects into schema.org

-another set providing a mapping into OBOfoundry entities, those using BFO as TLO as 'first line resources'.

Obviously, The profiles could have been merged  but it shows the schema.org coverage gaps as soon one moves into specific biological description. One could also see areas where coverage by OBO resources was wanting.

4. connecting the 2 worlds:

The mechanism schema.org offers is to use Defined Term/CategoryCode/MedicalCode to identify things like LOINC, ICD9 or something like DOID,MONDO or UBERON to bridge to Terminologies external to schema.org.

5. In the bioworld, OBOfoundry resources are deeper into 'interoperability and reusability' as Phenopackets specifications and others programs demonstrate, simply because the resources are domain specific and for many, state of the art representation of a knowledge domain.

I am sure some of you have already looked into this in much more details and studied the impact on classication.  If there are publications on this topics, pointers would actually be quite handy.

Best wishes

Philippe

[1]. https://datatagsuite.github.io/context/ || https://github.com/datatagsuite/context || https://w3id.org/dats/context

[2]. https://bioschemas.org/types/

[3]. https://schema.org/Dataset

[4]. http://blog.schema.org/2020/04/covid-19-schema-for-cdc-hospital.html

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAAkf34zAy4km3dnxURLo%3DgOcs3OSB9uuqhRRf8NWx1X81_VYtQ%40mail.gmail.com.

[LJ.Garcia]

Dear all,

In addition to Bioschemas, there are other science related initiatives using schema.org to markup landing pages: Research Metadata Schemas (working group in Research Data Alliance), https://biothings.io/, scienceonschema.org and Codemeta. The idea is to provide scientific communities with guidelines so their schema markup is compatible with each other, can be used for discoverability and some basic interoperability (e.g., gathering common metadata or creating summaries like those when searching for a movie or looking at a protein in Wikipedia). The idea is not marking all up (it would make some web pages a bit heavy) but enough, mainly for discoverability. Such communities commonly define a mapping or crosswalk in relation to other available schemas, e.g., Datacite for marking up datasets. As far as I know, none of them has done a mapping to BFO.

Some of the types and properties in schema.org were developed having in mind products and services (a lot taken for GoodRelations ontology), so we have properties such as isRelatedTo only for Products and Service. On the bibliography-related types, some things were also taken from the Bibliographic Ontology (BIBO). There is also a good number of types and properties about Health Care. Nowadays, I understand that schema.org wants communities to show usage before adding new stuff there(so they make sure new types and properties will be indeed used by a good number of people, so not sure they would want to include BFO with no clear use case).

What would be the use case there? I can see how a crosswalk from BFO to schema.org would benefit communities using schema.org to markup their pages and BFO to model their data. It would make it easier for them to see how to move from BFO to schema.org. Maybe something to explore. Maybe another one to look at could be Semanticscience Integrated Ontology. But it all depends on the data you are looking at. For the schema Dataset/DataCatalog case, for instance, a crosswalk to Datacite or DCATS are common as both of them relate to datasets.

The approach followed by some of the schema.org-science related project is more or less ontologies are for modeling concepts in a domain, they are great and serve a particular purpose while schema.org is for adding structured markup to web pages so they can be more machine-discoverable while also allowing new services for people (for instance the summaries I mentioned earlier). You can twist, stretch and adjust schema.org types and properties to make them more useful for your community, even if from a semantics point of view it does not always make sense. In schema.org you can even use the same property with different aims (or at least a bit deviated from what the description says), as it is the case of citation for Datasets.

Regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/c2139548-928d-1d0f-820a-2c1353fc8a3c%40gmail.com.

[James Hudson]

Hello,

I have learned a lot from this discussion so far.

The motivation behind my question is that I am involved in building an ontology. Among the first steps is to select which common top level framework to use. Two popular frameworks are BFO and schema.org. My goal is to avoid the silo'ing and wheel reinvention problems mentioned in B. Smith's excellent Introduction to Basic Formal Ontology (Sept 2019) video.

I am not sure what is meant by the idea that schema.org is lightweight, logical speaking.

However, this may, in part, involve terms like rdfs:range and rdfs:domain. Schema.org does not use rdfs:range or rdfs:domain. Their related terms are sch:rangeIncludes and sch:domainIncludes. Focusing on rangeIncludes, I believe the difference is that sch:rangeIncludes does not require instances of the object be instances of all of the classes in the rangeIncludes.  For example, an instance of the https://schema.org/byDay property can have a value conforming to iCal's syntax or https://schema.org/Friday. I can see how rdfs:range would support stronger logical formulations. However, what is appealing about sch:rangeIncludes is that it seems to be able to capture the messy real world better. Is common for there to be more than one rdfs:range for a property in a BFO ontology?

In any case, these are just thoughts swimming around in my head. I look forward to reading the thoughts of others.

Regards,

James

[Hyunmin Cheong]

I have done some work perhaps related to this...

I have used BFO to annotate an existing JSON schema to translate the schema into OWL axioms:
https://www.sciencedirect.com/science/article/pii/S2351978918313726/pdf?md5=dffbbcba07d305e3a844d78deba58924&pid=1-s2.0-S2351978918313726-main.pdf

One big benefit I found was that, once the JSON schema is mapped to BFO, one can automatically infer relations that are implicitly expressed in the schema. From the paper:

"JSON Schema does not include explicit definitions of relations between data objects, but only has a single relation type via “properties” that implicitly carry different meanings depending on the data objects involved. A method was developed to disambiguate such relation and map it to a corresponding OWL property defined in an ontology. The goal here was to automate part of the overall mapping process, which can be achieved by using the technique presented below and a set of generic relations already defined in a formal ontology [BFO].

If we assume that data objects have been mapped to corresponding OWL classes and the ontology contains a set of OWL properties defined with domain and range restrictions, the problem can be formulated as follows: arg min x∈P dist(domain(x),range(x)) where P is a set of OWL object properties, x, defined in the ontology. dist(a, b) computes the shortest path between the classes a and b where the ontology is transformed into a graph as follows: nodes represent classes and edges represent the existence of subclass axioms between the classes or object property axioms with the classes defined as its domain and range. This equation can be solved with any algorithm used to find the shortest path in a graph."

It seems like schema.org does not have/use relations. Mapping to BFO could allow the inference of relations in data.

[Pierre Grenon]

Hello,

1. Your ontology effort:

Since nobody is asking, let me ;) Can you tell more about your project? Which domain? Why do you need an ontology and what's the intended purpose, if any?

2. Logical complexity:

I think this is mostly about structure and expressiveness as well as the facilities provided by a natural or intended knowledge representation --- BFO, while it has in parts been delivered in RDF type thing is using FOL as baseline. The following link is somewhat old school, and perhaps not going as far as you would find it useful, but have a look at the quick discussion, it gives you a quick yet still pragmatic vibe of what is meant and at stake:

http://www.cs.man.ac.uk/~stevensr/onto/node14.html

3. Picking an upper ontology:

3.a Prefatory comment on why schema.org at all in the first place.

Let's be very clear on one thing.

When you create a framework in which you annotate resources, you have to deal with two elements that are conceptually different even though you may end up dealing with them in somewhat similar ways:

- First you need to have a catalogue of the types of resources you are going to annotate (for example, books or sections in a book) and you also want to have a number of attributes (for example, book's author(s), book length or page number on which a given section starts) that you want to record about the instances of these types.

- The second thing you need is an account of the domain(s) of things you use in order to annotate these resources (for example, people as authors or geographical locations if you intend to annotate touristic guides, say).

- There is one little subtlety that in some cases you also want to relate the resources you annotate (for example you say a paragraph is part of a chapter).

Now this may be overly simplistic. Yet, when you start that sort of things from scratch, which types of resources and which attributes you pick are highly dependent on the application you have in mind, the technology you have access to and most importantly the availability of information you can anticipate to be able to register. This is an engineering effort. When you do this in a specific context, there is an economy of those things. The point, however, is that you separate the view you have on resources from the view you have on domains used in annotating resources. If you handle them modularly, you gain much more flexibility. 

Schema.org is a large collection of things of the first type (stuff to annotate). It is organised hierarchically (as said earlier in ways that are not necessarily agreed upon by BFO in the first place but that is irrelevant). It also picks a number of 'standard' attributes for things you find on webpages that correspond to interpreted instances of its types.

The only reason you pick something like this to start with as an ontology is that you have no ontology in the first place or you don't have the capability or capacity to develop one. If you use it as a framework for annotating things of the right sort, you are using the resource well. For any other purpose, you are misusing the resource and you have to accept the trade off whereby in effect you just use this because it's there. It is not a negligible reason because at the end of the day, it is there...

While you can structure a typology of resources to annotate as an ontology, this is a special case and it is not usually what a domain ontology is. A domain ontology is an account of the domain.

3. b Common top level framework

Rightfully, when you span domains, it is a good thing to have an upper level framework --- this increases consistency. Rightfully, when you design a new ontology you may wish to adopt a methodology that guides you in your ontological engineering work and that is also the justification for upper level ontologies.

So back to question 1 and what this is about and what it is for, what multiple components you expect to have to unify through a common framework.

When you come to look into this, BFO may be an option. There are other good ones, DOLCE is good too and there are others: https://en.wikipedia.org/wiki/Upper_ontology

I'm mindful that some of what is said here is arguable. I find, for myself, that the distinctions are useful. They do not remove similarities and they do not prevent you from using something designed for one purpose with a different purpose in mind but I think it is the sort of thing worth being clear about when you make the sort of choices you want to make so you know what your trade offs are and what you potentially buy into in terms of sustainability and cost for your efforts. I'm very happy to hear a different tune and being challenged on any of the above, use it if it's useful, don't if it's not...

Cheerio,

Pierre

--

You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAEUVO9HE2tZUT87rVZy1oNW-%2B%3DeQ3xfetNsE4ad%3DbZyCWN5vAg%40mail.gmail.com.

[James Hudson]

Hello Hyumin,

Thank you for your reply.

I am not sure what you mean by schema.org not having or using relations.

For schema.org, nodes are classes and the edges represent properties. They do use a notion of domain and range, but instead of the rdfs:domain or rdfs:range, they have sch:domainIncludes and sch:rangeIncludes which have looser definitions as already noted.

Regards,

James

--

You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/aa827c4f-cc81-4e66-96e7-30ed08eee753o%40googlegroups.com.

[James Hudson]

Hello Pierre,

Thank you for your reply.

1. 

I am deliberately not going into that as I think it would only cloud the discussion and make it harder to discuss in a general sense.

2. 

I had just assumed that BFO was using RDF as a baseline. An advantage of RDF is that representation in graph databases, like Neo4J, is straightforward. I am not familiar with FOL. Is the same true of FOL?

3.a.

I think one reason to select something like schema.org would also be that there is no need to recreate what you need. It allows ones capabilities and capacities to be focused on one's problem area rather than first reinventing a wheel that already exists. I agree that there is a problem of misuse. I also agree that if one is selecting something like schema.org (or even BFO), because it is there, is a mistake.

The reason why I have considered schema.org is that it appears to supply classes and properties I needed, potentially saving me the time and effort to recreate them. It appears to cover areas that no BFO ontology has covered yey considering the scientific focus of BFO to date. There does not seem to be any reason why those things that the average person runs across in their everyday life could not be represented by a BFO ontology, but there may be advantages in the schema.org concept of sch:domainIncludes and sch:rangeIncludes that make this easier if less formal logically.

3.b.

The issues you bring up here are why I would like to understand BFO a little better. It is why I wanted to focus on the concept of rdfs:range and how that is used within BFO vs. the schema.org concept of rangeIncludes. However, considering my misunderstanding that BFO is built upon FOL, that comparison may be difficult.

Regards,

James

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAAkf34y8PKeXwq-env9LSmO3JMV-a-J%3DvoPQ5kT6X8OacF3fng%40mail.gmail.com.

[Chris Mungall]

Hi James

Let me clarify a few things:

domainIncludes and domainExcludes are in schema.org because people want to specify a disjunctive list without making an explicit UnionOf construct (schema.org is meant to be simple). Of course, this means that you have to toss the open world assumption of RDF out the window, but I doubt they care.

BFO doesn't use RDF as a baseline. The version of BFO most people use is the OWL rendering, which is based on a written specification. There is also a FOL version forthcoming.

Although OWL can be rendered as RDF, the problem of rendering OWL in Neo4j as a property graph in a useful way is not trivial, due to the profusion of blank nodes produced either to represent OWL axioms or reified statements. There are multiple approaches, e.g https://github.com/cmungall/owlstar or https://protegeproject.github.io/owl2lpg/

However, representing the subset that would be useful for certain applications is much easier. For example, a hierarchy of nodes with properties such as uri, label, definition. I don't think there's any use case for representing a complete axiomatization in neo4j. It doesn't really matter whether the starting point is OWL or FOL.

But this gets back to the question: what's the actual use case here?

It's hard for me to see how schema.org and BFO could be of mutual assistance. If I am searching for a book online, it's maybe interesting for me to philosophically ponder the fact that I while am *searching* for a generically dependent continuant (I don't want one search result for every copy of the book), my intent is to *buy* a material entity (usually an object, but if it's a trilogy it might be an object aggregate). Oh, unless I have a kindle, then I may actually want to buy a concretization.

But if schema.org was to adopt this kind of organization and partition the basic concept into different BFO categories, no one would use it.

There is a nice paper by Barry and Werner I read a while ago (sorry, do not have the reference) that spoke of a 3-level of division of reality, with (AFAICR): the world; our conceptualization; our representation. I think a common error is using BFO to try and directly represent the 2nd two.

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAEUVO9F%2B-tBw%2Bh1mJH1yjW4VRUm81MpftgP1hs-Lz3jKiBD-pQ%40mail.gmail.com.

[James Hudson]

Hello Chris,

Thank you for your reply.

I am not sure how schema.org is tossing out the open world assumption of RDF. What does this mean?

With respect to the paper regarding the 3-level division of reality (the world, our conceptualization, our representation), if one needed to represent the second two, as schema.org does (?), is it the case that (a) BFO is not a solution for the problem or (b) that the problem is poorly defined or understood? Based on your comment (assuming I understood it correctly) that if schema.org were to adopt BFO categorization that no one would use schema.org, the answer would seem to be (a).

Regards,

James

To view this discussion on the web visit https://groups.google.com/d/msgid/bfo-discuss/CAN9AifsOS3zc6h3eA3CvZjeJy%3DEfeZQ3zpXXuADfXUMWAyCUSQ%40mail.gmail.com.