Discussions on sandos

I also think this is a bit too messy. For example, many of the entries are in fact format families (e.g. PDF) and so do not provide an easy way of identifying different versions of the format (e.g. PDF 1.5 does not have a Freebase URI). Perhaps we could add a 'Bitstream Encoding' entity (which may be embedded in another, or may act as a stand-alone file) and then point the current Format entities at these. For example:

PDF . has_version . [Bitstream Encoding: PDF 1.6]

But perhaps this will turn things people think of as Formats into Encodings and they won't be able to find them?

sandos's type Serialization is probably relevant here to help distinguish format models from their serializations.

Versions of formats should probably just be modeled as separate topics, particularly if there's any significant compatibility issues.

The extended_from property can be used to link things together, but it's not always 100% accurate for families of things which are more related by branding or continuity than technical compatibility. Not sure how finely this needs to be modeled though...

Sorry for the delay in replying - I didn't get any notification email, and I'm not sure why as I've allowed it in my profile.

I agree that we should distinguish between models and their serialisations, although sandos's type still does not distinguish between specific encodings (e.g. XML rather than XML 1.0). That would imply three levels: Specification/Model, File Format, Serialisation/Encoding/Version.

I'm not quite sure how to align the Model/Specification with the more common file formats. For RDF, there is a well-specified model and a range of encodings. For things like 'Images', the model is less well specified (rather, the core concepts are well-specified, but there are a lot of additional complications that vary between formats), so the mapping is not clear.

I agree that version of formats should be separate topics (as I would like URIs for each), but I'm not sure if I would prefer different instances of the 'File Format' type, or a new 'Serialisation' or 'Encoding' type. I suspect that, for now, it might work better if we augment the File Format schema and use that for both file format families and specific encodings. We could add fields to distinguish them, and let things develop for a while before we attempt to prise them apart into separate entities.

The semantics of 'extended_from' are not clear to me. It has no description in the File Format type, and does not indicate how it should be used. For me, it is critical to be able to distinguish between direct super/subset relationships of encodings (i.e. XHTML is also XML, but a more specific subset - technical compatibility if I understand you correctly) and other relationships (e.g. HTML5 is a later version of HTML4). Without clear guidance on what extended_from means, the data will become chaotic.

I would really like to work out how to move this forward. It seems that the user who created the File Format type (superkurt) is long gone. How do we help make it better? Who should we talk to?

Shawn - this is really cool.  You really took this to the next level.  I especially like the  ontology_attribute_mapping taking not only a property but a type (indicating when the property mapping applies.  Alexb suggested this to me a while back - but I never got around to adding it!)

I'm not sure that I fully appreciate the ontology_class_mapping connecting with general Freebase Topics.  Do you have a specific use in mind for that relationship?

One thing I had toyed with (on sandbox a few months ago) was adding the ability to map not just  Freebase to other ontologies, but allowing multiple ontologies to be mapped together. I think it begs for ontology properties to be represented as objects themselves that can be linked together.

Have you written any code against this? 

I'd love to collaborate on this if you are interested and see if we can get a larger community involved (and using it!)

Jamie

Thanks Jamie, I really got inspired by the domain you created.

The reasons why I linked equivalent classes to topics are two-fold. First, I  wasn't able to create reverse properties from a Type as easily as I could to my own Ontology Class type. More importantly though, I wanted to link multiple ontologies together as well as with Freebase.

By linking classes to topics, it means that you can search for a topic like Country and get a list of equivalent ontology classes from many different ontologies. My intention was that these topics would then by typed as Type/Domain Equivalent topics as many of them already are. You can also leverage the Also Known As property of those topics to help map ontologies together. As you mentioned, it would probably be a good idea to do something similar for properties.

Ideally I would like to map Freebase to UMBEL because they have mappings to Cyc, Dbpedia and other ontologies. I am starting to write some code to help map the 1,300 or so top level Freebase Types onto the 20,000 UMBEL concepts but that will take some time.

I'd be happy to do what I can to get more people using Freebase as a common ground for ontology mapping.

hey, you guys are smart, and should be working together.

which one should i import to?

Spencer, Shawn -

I continue to work on various "services" that use pieces of my ontology domain (things like the prototype: http://rdfvocab.freebaseapps.com/ that I plan to incorp into the RDF service endpoint.)

I have some small changes to make to the vocabulary schema to aid (and simplify) the mapping semantics.

Spencer, I'd be excited to have more data to work with - and it would help me refocus on the mapping applications if you are interested in contributing data.

J

Well they built and operates a fiber network. They dont provide end-user services on it though, but let others do that.

Not sure what industry fits best there. Something "network operator" related maybe.