Discussions on Computers

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

Aseem,

I don't see that this would add any extra functionality in terms of MQL queries, but rather provide additional useful information when viewing topic pages of software licenses with the freebase client.

I see this as being similar to types such as "Computing Platform" which display a list of file formats that the platform supports (e.g. on the "Microsoft Windows" topic page). This reciprocal property is not strictly needed as the information can still be found by issuing an MQL query, but makes finding the information a little easier.

However, I'm still a little new here, so feel free to point out any reasons why you feel this property would not be useful that I may have missed.

David

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.

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. 

I agree that /computer/internet_protocol overlaps /internet/protocol, but I'm unclear on where non-IP protocols live in the proposed scheme.  This includes things like all the IEEE 802.* LAN protocols, OSI protocols, ITU-T protocols (X.400, T.* protocols for fax, teletext, etc) -- basically everything in this table http://en.wikipedia.org/wiki/OSI_model#Examples which is in a column other than "IP suite."

The current /computer/internet_protocol type includes an even wider variety of stuff like graphics terminal protocols (VT100), dialup transfer protocols (XMODEM), etc.

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

Hi Alex.

That's a very good point. However as you know processor families generally tend to have a range of possible clock speeds depending on the specific model of the processor. Considering that the range can be pretty large (even ignoring the overclocking possibilities) would this really be a useful property? Do you have a specific use case that this property would address? Or are you suggesting that there ought to be separate topics for specific processor models with each having its own clock speed specified (which could be quite useful for certain apps)?

AM

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. 

Hi sandos,

 I've added "versions" as a property of Software License to accomodate this. Let me know if anything else is needed to model this properly, as I'm not an expert in license stuff.

 Thanks,

Vishal

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 

Yes, what you call the "book" domain is really the Publishing domain -- the trouble is, changing keys (/book in this case) will break any query, view, or application relying on any data that uses the key (which, in this case, is the entire publishing domain). So we try not to change keys, ever.  If you start poking around, you can find all sorts of things where the display name and key are very different.

The author type is about as general as it's possible to make it, I think.  It's trivial to make a query than can constrain by type of work written, so maybe the canned query should be updated.

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.

Short answer: no. Freebase is a data commons. All data in it is publicly available. Some of it is harder to find than others (such as unpublished domains) but anything in Freebase can be found with the right query.

While the data in Freebase is licensed under a few different open data licenses, the software underlying the site is currently the proprietary property of Metaweb Technologies. Currently, we are focused exclusively on building the data commons; it is possible that private metawebs will be available at some point in the future, but for now, it’s all about the Freebase commons.

You seem to have mistaken Freebase for a relational database. (-:

I note that your new type is full of text-valued properties that really should expect other types. Take a look at the Software type, for instance; the “Compatible Operating Systems” property expects a Software Compatibility type that links which links the OS and the versions in a compound value type (CVT).

You would probably benefit from checking out the Creating Types and Properties help pages, particularly the Data Modeling Guide. I think this will help answer questions about the views, as well.

Hi Tracy.

Great work. I have a couple of questions/comments about the type schemas you have created.

From my point of view, not all files need a crypto hash. It definitely makes sense for files that will modify the system properties i.e. installers, os isos etc. and thus need to be verified as to their original content, however I am not quite sure I see the utility of having this information for, say plain text or pdf files. My guess would be that there are more 'pure content' (for lack of a better phrase) documents in the wild than installable softwares and programs for which the users need to be sure of the integrity of the content. Since you do plan on adding more specific filetypes, I would recommed adding the property for filetypes that generally have hashes released with them or for those filetypes that one can justify having associated hashes. If however you find that it is more convenient and useful to simply have the property in (in my experience it has been a bit hard to tell in the design phase) feel free to leave it in.

Also I was wondering as to the rationale behind having the contained work as another type? Wouldnt having a multi-valued property in the document itself (that pointed to the original work) work.If the rationale was to have an overarching type that allows you to embed any 'work' in an electronic 'container' it definitely makes sense. The name appears to be a bit ambiguous as the nature of containment and the container itself. Unfortunately I do not seem to have an alternate name for you, but that is something you might consider.

Once you are done with the schema development, please post back here and I will promote it to the main domain.

Thanks.

AM

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.

Hi.

Certainly sounds like a good idea. I think that the properties for an API in a non-web services context might be bit different. I would encourage you to go ahead and model it in your domain and if it works I will be more than glad to promote it up.

Thanks.

AM 

Hi Chris.

OSS and repository appear to be very useful types. I would like to add that it may make more sense to add the software repository type to the software type itself. Other than that it looks great. 

AM 

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