Discussions on Computers

There was an earlier discussion of RFCs and Protocols on the data modeling list that I was supposed to follow up on with the with the following email:

=====
Thanks to both Robert and Tom for the very in-depth answers. The confusion over the /computer/internet_protocol type is well deserved. I just discovered another type, /internet/protocol, which has a description and is also connected to the /internet/api type, which uses it to describe methods of accessing a certain API. 

Based on all the feedpack, the changes I'm proposing regarding protocols are:

1. Obsolete /computer/internet_protocol type
2. Clean up /internet/protocol to only include the IP suite of protocols; most bad instances should be /computer/file_formats

The revised changes and additions regarding specifications/standards are:

1. Create a Standard type
2. Create an RFC or IETF Standard type (and any others, like ISO Standard, IEEE Standard) that includes Standard
3. Create a Standardized Object(?) type to place on any topic standardized by a Standard

This way internet protocols will link to their RFCs via a property on the Standardized Object type. I will also add all the properties Robert and Jeff suggested to the IETF Standard type:

     - Obsoleted(Superceded?) by and its reciprocal, Supercedes
     - Updated by and its reciprocal, Updates
     - Authors
     - Working Group
     - Standard number
>    - Status (informational|experimental|...)
>    - Date published (/type/datetime)
>    - Specifies protocol (internet protocol)

The title will be captured in /type/object/name. None of the properties that link to other RFCs need to be unique, from what Robert has said. As for RFC ids as keys, we can figure this out later. I believe URI Templates only work with keys, so that will be an interesting issue later on.

(possibly replace any occurrence of "Standard" above with "Specification")
=====

In short, I'm in favour of deleting the Internet Protocol type from Computers. 

Looking at theSoftware type it appears that a more generic use of Protocol could instead be used to capture those that are not necessarily Internet Protocols (those maintained by standards bodies and used in relaying devices, both hardware and software driven) as is mentioned above from others.

My use case for this is the Xboard Communication Protocol which is used in several chess programs and chess engines such as Crafty

So, can we get the above proposal from Vishal documented at least here: http://wiki.freebase.com/wiki/Internet_commons and been to gather comments on the mailing list and REALLY finally make some progress on all this ?

Comments for me to add to above proposal, so I don't lose them: My thoughts are that we have /software/protocol and /software/library. Further, an additional property like /software/apis_provided(_if_any)

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?

I've updated my scratch type per your suggestion. The "instance of myself" thing has always seemed a little weird to me (it's used for one-design boats too), but it seems to be the Freebase standard.

I've added the types to FROSTBURG. Feel free to play around with it and suggest other additions (I didn't think too deeply about it when throwing it together).

Just noticed this. Sorry for the delay, Thad. As things stand right now, this would probably fit in the File Format type which is used for all kinds of encodings.

Without reading up on it, I"m guessing that iXBRL is either a different serialization of XBRL, a subset of XBRL which is XHTML compatible, or a little bridge container mini-format for embedding XBRL (or subset thereof) in XHTML. I think any of these would probably fit the current usage (which is kind of all over the map).

As we refine the modeling we can adapt the things which have already been typed.

Tom

p.s. I don't know of a good example which has already been done in Freebase.

Thanks Tom.

I've modeled iXBRL - inline XBRL as extending XBRL for now.

Now it seems we have an extending problem within the /computer/software realm. My started thread for that question here: http://www.freebase.com/discuss/threads/m/0cmz_bg

The way this type is currently used, it's a little bit loose. It can be used for both corporations who develop software (which would be the Simile equivalent) and for individual people. I'm not sure this is necessarily a bad thing since you can work out from the other types which you are dealing with.

Is there a particular circumstance where this is causing you problems or is it just a matter of it intuitively seeming like a poor fit?

(Cross posting to the Software Developer type and its domain, Computers, to see if anyone watching there has a strong opinion one way or the other)

Hi David.

Is there a specific use-case that you have in mind that cannot be satisfied by simply querying for software with a specific license as opposed to 'for license X give me all software'. I am not averse to adding the property, however I would like to understand what we would gain by this additional property that cannot be provided by the existing schema.

AM

Bumping this old thread up.

I'm tending to agree with David here that it would be nice for the client to display the pieces of software which use each license. It's just a matter of reciprocating the existing /computer/software/license property. As with any other reverse property, it doesn't really add any new functionality, but it makes things a bit easier in some cases.

Any other views?

I've been a software architect for most of my career and I'm not sure what useful properties you'd capture with a software architecture type.  I supposed you could try and capture general architecture category like client-server, 3 tier, n-tier, SOA, whatever, but there's not really a ton of value in those categorizations.  An architecture is really just a very high level design, for the most part.  Alternatively, it's just a label that people apply when it suits them, without a lot of useful semantics.

The current Computer Architecture  type is actually kind of a mish-mash (System/360) as well as categories/types of architectures (e.g. Harvard architecture).

BTW, this was my initial comment on the subject back in February 2009.  Perhaps the difficulty in treating the subject in any useful fashion is part of the reason it remains undone.

The hardware architecture piece might be helped by a review of a standard text like Hennessy & Patterson to see how they classify things.

Yes, please.  Seconded.

Perhaps a description for the type too?  Does this encompass only things defined by the IETF or any protocol that runs over TCP or UDP or any protocol run between two computers?

Please see discussion I started on the data modeling list:

http://lists.freebase.com/pipermail/data-modeling/2009-April/001673.html

I imagined a compound value on the Computer Type, linking the CPU model and the speed it is clock at.. on that specific build.

As you pointed out, CPU models often have a huge range in Clock amoungs other things. But this doesn't even take into account that on some systems the CPU is either under or over clocked, like the Asus EEE 901 range, and the Nokia N800. The N800 has a 400Mhz (stock) CPU but is Clocked at 330Mhz.

With technology like Intel's SpeedStep I expect this type of situation to become a lot more common. 

That makes sense, but I question putting authors under the book domain. I had put myself down as an author as I've authored a couple of papers, but then I was randomly browsing the canned searches for ivy league authors and found myself there along with Fitzgerald and Feynman, which feels wrong somehow. 

 If we eventually import large corpora of scientific papers, searches like Ivy League authors will deviate from what (I assume) people intend when they named a query like that. Of course, it could be further refined, but as I said, it feels weird to have a type of book/author when I've never written a book (and likely never will!)

Maybe the author type could be made more general to allow for clearly marked scientific papers, journal articles, newspaper articles, and the like? And the book domain (in the URL, I mean) be renamed to match its human-readable title (Publishing)?

 I dunno, maybe it's silly to give the URL so much weight :P 

Ah, I see. That's a pity, but I guess having book in the URL isn't the end of the world.

I would think that domains like that would've just been other unique IDs in the database, whose URL representation was just another key, though? If I look at it in the explore view, it seems to have guid #9202a8c04000641f8000000003cbf74b and id /book, which would imply (with my limited knowledge of the system) that the URL could be changed without breaking any internal data relationships (but would break external links). 

It seems like as you said, many domains change significantly from the time they were conceived, and that having a more flexible URL scheme that accurately matches the intent of the domain would ultimately be more effective. Maybe it would be possible to change the id from /book to /publishing and create another /book that redirects to publishing, somehow?

Anyway, just trying to understand the way things work here more :) It's not that big a deal. 

It’s true that the system itself would survive any arbitrary change in IDs, or even their complete destruction.

However, at some point, external applications need to talk about things, and the IDs, constructed from those keys, is the way they do it. So the canned Ivy League author query looks for the type whose ID is “/book/author,” so if the ID for the domain became /publishing instead, that query would no longer find anything. Any other publishing application deployed in the wide world would similarly break. For that reason, we try to be very conservative about changing any keys in the commons domains.

Thanks for the reply. In order, then:

The cryptographic hash can be useful for a number of reasons. The first example that comes to mind is that it would allow for an application to be built which would hash a file and then query Freebase to see if it was catalogued, and in this way the user could get info about a file. So the hashes are more for the sake of identification than verifying integrity, though of course they serve that purpose as well. Too, many files that are released on the internet, including software,videos, and such, have an MD5 or CRC32 hash (or both, or more) listed with them, so it's the sort of information that is typically associated with files. Since hashes can be generated for all files, it seemed more appropriate to have it on the generic File type rather than more specific ones.

Regarding Contained Work, yes, the idea was definitely to allow anything to be contained in a file (indeed, there's no particular reason why the container must be a file). I demonstrated this by having pandp12.zip contain pandp12.txt which contains Pride and Prejudice. Actually, the text file probably should contain a particular edition of the book, now that I think of it. I'm not at all in love with the name, but it was the only thing I could think of at the time. I'll try to come up with something else.

I'd like to create a type for video files as well before I decalre File to be finished, to help me see if I've missed anything vital, but I feel like what I have is pretty stable.

Thanks again for the reply. If you've got any suggestions, or further questions, I'd be happy to hear them.

Aseem,

The Software Repository type is a join model that connects a project to a type of revision control system and adds some additional properties like where to get the code. I'm not sure how to model that without an additional type. Also some software projects (like mine) expose more than one repository and synchronize them, however this is not the norm and only one of them serves as the canonical repository...

 -chris

In that scenario, I would recommend creating a CVT called source-access which would have two properties: the URI and the protocol (you can additionally add the source control as a property too). That could then be linked back to the software and would provide the level of expression you want.

HTH

AM